[opensource-dev] Client-side scripting in Snowglobe
morgaine.dinova at googlemail.com
Fri Feb 19 15:10:16 PST 2010
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
On Fri, Feb 19, 2010 at 10:50 PM, Edward Artaud <edward.artaud at 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 <lenglish5 at cox.net> wrote:
> > Maggie Leber (sl: Maggie Darwin) wrote:
> >> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud <edward.artaud at 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
> > 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
> > prim. One could manipulate the vertices of the sculpy via a plugin and
> > the changes show up in the client without putting extra strain on the
> > The state might be shared via p2p connections between clients' plugins,
> > collaborative clients could share state 2 ways via a server (or p2p),
> > 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
> > 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
> > way and manipulate anything from a prim or texture all the way to the
> > scenegraph. physics could be modded the same way. Likewise with custom
> > scriptable objects.
> > This is basically a hybridization of the croquet/cobalt strategy for
> > worlds and the VWRAP strategy so anything you could do with either should
> > possible this way.
> > Lawson
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev