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
