No Edward, client-side scripting is not related to in-world scripting at all. It's scripting OF THE CLIENT, and it has the sole purpose of extending the functionality of the client, on a personal basis.
While it's nice to hypothesize about in-world scripts being off-loadable to the client, that is merely a conceptual idea without any concrete suggestion for how it could be implemented. It's not what we've been talking about here. Morgaine. =================================== On Fri, Feb 19, 2010 at 10:50 PM, Edward Artaud <edward.art...@gmail.com>wrote: > I'm certainly not against a general API for trusted plug-ins > (certainly all my emails to this list have been plug-in related), and > it would be awesome for tools to be built without everyone having to > create a viewer fork. My assumption, however, is that client-side > script capability is meant to go hand in hand with the server-side > script memory limits, where if the script developer marks the script > as "run on client", they're able to run without the same memory limits > as running on the server. If the client-side scripting project isn't > part of the same initiative as the server-side script memory > restrictions, it certainly should be, since one is the elegant > solution to the other. > > On Fri, Feb 19, 2010 at 2:29 PM, Lawson English <lengli...@cox.net> wrote: > > Maggie Leber (sl: Maggie Darwin) wrote: > >> > >> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud <edward.art...@gmail.com > > > >> wrote: > >> > >>> > >>> For client-side scripts to be something worth > >>> prioritizing implementing in mainstream viewers, their usage must be > >>> based on the assumption that some large percentage (80+% maybe) of > >>> attachment scripts, for example, would be running client-side... > >>> > >> > >> Uh...I didn't really see viewer-side scripting as something that would > >> make any significant dent in what's done today with scripted objects > >> serverside except in the case of some HUD objects. > >> > >> I was thinking of this as new function, and only incidentally > >> providing some marginal performance relief for LLs servers in limited > >> cases...such as how Emerald's avatar radar reduces or eliminates > >> avatar radar HUDs. > >> > >> Love to hear other views on this... > >> > > > > Depends on what is being done with it of course. a squeak interface (say) > > tied to the socket/shared memory connection could prototype just about > any > > kind of extension/facility (as long as it used already existing events). > > > > Suppose, for example, there was a way to use the media plugin's shared > > memory as a sculpty map rather than simply as a texture to be painted on > a > > prim. One could manipulate the vertices of the sculpy via a plugin and > have > > the changes show up in the client without putting extra strain on the > sim. > > The state might be shared via p2p connections between clients' plugins, > or > > collaborative clients could share state 2 ways via a server (or p2p), > while > > an audience could subscribe to a one-way connection of some kind, or the > > animation could be cached in a distributed file, or it might not be > shared > > at all if someone were working on a test of a new animation and wanted to > > see what it would look like in-world before distribution. > > > > One could have high-end content creation tools hooked into the client > this > > way and manipulate anything from a prim or texture all the way to the > full > > scenegraph. physics could be modded the same way. Likewise with custom > > scriptable objects. > > > > This is basically a hybridization of the croquet/cobalt strategy for > virtual > > worlds and the VWRAP strategy so anything you could do with either should > be > > possible this way. > > > > Lawson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
