Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

capability by contract

Lotka Zagoskin
Registered User
Join date: 30 Sep 2006
Posts: 40
11-11-2006 23:25
so, if for whatever reason LSL can't be changed to provide more capability, either in memory or function, why not make the interface to the outside, to other servers, richer and faster? i understand why Lindens want to throttle llHTTPRequest, but perhaps there's another way they can let people extend function for prims in SL relying upon fast interactions with other servers?

i'm thinking that they might do a W3C-like interface specification, starting it at a developers' conference, and then continuing the discussion until such an interface is solidified and trial implementations are available. in particular, the effort might avail itself of Design by Contract ideas, so implementations declare and thereby promise they will restrict themselves to certain resources or time slices, and if the SL side detects a violation of these promises, it kills the connection.

throwing load onto others seems to be a way of fixing this conundrum and allowing SL scripts to grow properly.

i mean, despite all the restrictions on scripts, the Lindens and Residents still encounter griefers and stability issues.
Raeyan Aldrich
Registered User
Join date: 14 Oct 2006
Posts: 44
11-12-2006 13:06
one problem with allowing a lot of bandwidth to non-linden servers is that people could deliberately attack other servers using LSL scripts, which would put the lindens right in the middle of any kind of legal action the attackee decides to take.
Lotka Zagoskin
Registered User
Join date: 30 Sep 2006
Posts: 40
yes, i've heard that explanation
11-12-2006 13:31
yes. i've heard that explanation. it's in the video. but you misunderstand.

if, in fact, a "design by contract" kind of protocol is used, the SL side simply cannot connect to a target without the target server permitting the connection. it would not at all be a bare HTTP connection, nor would it replace the one in hand.

moreover, once authenticated, there would be a "contract" regarding how much of a resource and how often it would be used, with the SL servers or the "plugin" (for want of a better term) at the remove server terminating the connection upon detecting a violation of the contract.

if indeed a remote server is being attacked because someone who has access to it has put software there which permits it, i don't think Linden Labs or anyone can prevent that at all.

i mean, once reasonable things are done to prohibit obvious misuse, Linden Labs or anyone might as well pack up if they are worried, say, about a terrorist group somewhere is meeting in an SL camp because it's easier to keep the conversations away from the snoops. hey, all kinds of things are possible. it doesn't mean it's worth building legal defenses against them.