Difference between revisions of "User talk:Void Singer/Teacup"
Void Singer (talk | contribs) m (→Minor Optimisation: reply) |
Void Singer (talk | contribs) m (Supporting Extended Return Codes?) |
||
| Line 1: | Line 1: | ||
== Minor Optimisation == | == Minor Optimisation == | ||
Great little script! Just curious though about this line: | Great little script! Just curious though about this line: | ||
<lsl>if (~llListFindList( [200, 404], [vIntDta] )){</lsl> | <lsl>if (~llListFindList( [200, 404], [vIntDta] )){</lsl> | ||
| Line 6: | Line 5: | ||
<lsl>if ((200 == vIntDta) || (404 == vIntDta)){</lsl> | <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?<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 06:24, 15 April 2011 (PDT) | 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?<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 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. <br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 19:53, 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. <br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 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?<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 20:13, 15 April 2011 (PDT) | |||
Revision as of 20:13, 15 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)