Difference between revisions of "User talk:Void Singer/Teacup"

From Second Life Wiki
Jump to: navigation, search
m (Supporting Extended Return Codes?: update)
(Is it supposed to work on 1.23.5?)
Line 28: Line 28:
  
 
: Phoenix(908) has it's own problem with the internal browser, in that the address field is limited to 255bytes. I'm going to try to pinch around it (I have some whitespace I can edit out) but I'll probably have to beg the phoenix devs for a back edit on that one. I'm not sure if that problem was simply imported with snowglobe code but I'll check Cool and see if it has the same problem.... if so then all v1X will probably have the same issue =/<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 09:47, 19 April 2011 (PDT)
 
: Phoenix(908) has it's own problem with the internal browser, in that the address field is limited to 255bytes. I'm going to try to pinch around it (I have some whitespace I can edit out) but I'll probably have to beg the phoenix devs for a back edit on that one. I'm not sure if that problem was simply imported with snowglobe code but I'll check Cool and see if it has the same problem.... if so then all v1X will probably have the same issue =/<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 09:47, 19 April 2011 (PDT)
 +
::Hmm. Well part of the problem was that I was just copying/pasting the scripts from the wiki here into my own objects and it wasn't working. I thought it would give me at least a default page, but the object you sent via group worked. The other problem that appeared is that clicking any of the links on the page causes the viewer to crash. :-/ [[User:Talarus Luan|Talarus Luan]] 13:11, 19 April 2011 (PDT)

Revision as of 12:11, 19 April 2011

Minor Optimisation

Great little script! Just curious though about this line: <lsl>if (~llListFindList( [200, 404], [vIntDta] )){</lsl> Is there a particular reason why you went for that in preference of a simple condition? As conditions are always faster: <lsl>if ((200 == vIntDta) || (404 == vIntDta)){</lsl> I assumed it was for readability or ease of editing, but I'm not sure there's really any advantage to searching a static list?
-- Haravikk (talk|contribs) 06:24, 15 April 2011 (PDT)

I was actually aiming for extensibility.... the 0.1 version actually supported 200, 201, 202, 204, 205, and 404 messages... so that code made a little more sense in that rendition. When I simplified, I just pulled out the currently unused codes to limit invalid link messages triggering the code. I should probably ad some of those back in, but I was considing allowing them to be used internally by file systems.... still kinda up in the air about it. but I'll make sure to comment it for now, and replace it if we reserve it for internal coms.
-- Void (talk|contribs) 19:53, 15 April 2011 (PDT)

Supporting Extended Return Codes?

Thoughts? should we support any codes that we can reasonably send? some codes we can't, because they require header information (pretty much all of the 3xx codes), or because of the behavior of the cap server (we can't send valid 1xx because the connection gets closed), and some will behave against expectation for the site (205 will reset the page, which effective takes it to the root for compliant browsers, although I've found Firefox and Webkit CLEAR the page). but others are very informative, like sending 204 for post page returns, or 202 for links that trigger inworld actions, etc...

so should we?
-- Void (talk|contribs) 20:13, 15 April 2011 (PDT)

I know I only waited a few days, but I figured with the new quick 404 handling that I'd run with this one, on at least a limited basis. I've added support for 201 Created, 202 Accepted, 204 No Content, and am using 100 Continue internally to avoid 404's on quiet slow File Services, and misusing 101 Change Protocol (only within the server prim) to tell the server to push the bootsrap page. I hope this makes sense to everyone, and if not I'm open to contradiction as long as alternatives are supplied.
-- Void (talk|contribs) 09:54, 19 April 2011 (PDT)

base46 image encoding transport?

Currently it's possible to embed base64 encoded files into the page IF those files are first channeled through javascript, or in some cases embedded in css files. I'm very open to any method we can use to do this transparently to page loading... for resource types that will accept a "type" attribute AND comply with it against the server's plaintext label.... if there are any.... otherwise they all have to wrapped.

the problem I've encountered so far is that no tags I've found support it, and it will force the page to use some sort of link loading scheme similar to what is used to load html pages now. this has two problems, the first and most major IMO is that we can't use normal tag syntax for things like IMG (because it may attempt to load before we can intercept the request), and secondly, it means that the user has to use custom commands in the page to load them... or direct embedding into the page (which would severely inflate page size)... things I would like very much to avoid.

if anyone has suggestions on a way around this, or thoughts on minimizing or standardizing the methods we do have available, I'd love to hear them.
-- Void (talk|contribs) 02:05, 17 April 2011 (PDT)

Is it supposed to work on 1.23.5?

All I get is a blank page, and it won't open in external browser at all (FF3.6) Talarus Luan 08:17, 19 April 2011 (PDT)

I'm having the same problem with all of them now... it'll open fine in the internal browser for v2, and you can copy the URL from there and run it in FF3.6, but for some reason the viewer is refusing to pass the url to external browsers, or it's failing some security check in between. I'm going to Jira that today (I thought I had already but I guess not). the odd thing is that I'm sure it was working in v2.6.1 =(
Phoenix(908) has it's own problem with the internal browser, in that the address field is limited to 255bytes. I'm going to try to pinch around it (I have some whitespace I can edit out) but I'll probably have to beg the phoenix devs for a back edit on that one. I'm not sure if that problem was simply imported with snowglobe code but I'll check Cool and see if it has the same problem.... if so then all v1X will probably have the same issue =/
-- Void (talk|contribs) 09:47, 19 April 2011 (PDT)
Hmm. Well part of the problem was that I was just copying/pasting the scripts from the wiki here into my own objects and it wasn't working. I thought it would give me at least a default page, but the object you sent via group worked. The other problem that appeared is that clicking any of the links on the page causes the viewer to crash. :-/ Talarus Luan 13:11, 19 April 2011 (PDT)