User talk:Void Singer/Teacup

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)

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)