[opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

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.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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/a3f19d13/attachment.htm