Re: [opensource-dev] Client-side scripting in Snowglobe

[Edward Artaud]

Smartest point made on the topic, and it really makes sense to stop
conflating the two, there are distinct untrusted script and trusted
plug-in problems.  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, and
possibly even allowing in-world objects to specify that specific
scripts as meant to run viewer-side as well.  The analogy would be
that of web browsers, most of which have javascript enabled by default
and any single browser user is downloading and running *thousands* of
scripts over the course of a day with no awareness or explicit
permission given.  Getting a similar system to work in the viewer is a
big problem in and of itself to solve, and the one that would have the
most direct impact in the in-world experience of the most users in the
shortest period of time.  Plug-ins would be great, but then we get
into the questions of the whole process of how installation works, is
there an auto-installer ala IE or some form of manual mechanism that
will be prone to user error.  If there isn't a way that a very large
number of users would have easy access to trusted plug-ins, it's hard
to imagine it would be a highly prioritized feature.

On Thu, Feb 18, 2010 at 11:16 PM, Ricky  wrote:
> I suspect that there are two things being discussed here without
> distinction: Client scripting, and client extensions.  Confusing the two is
> easy.
> Client-side scripting SHOULD be sandboxed, and in a controlled set of
> languages.  For a close example think of javascript in web browsers.
> Client extensions, or alternatively named as "plugins", would be modules
> that can be plugged in and out of the client and run /as if/ they were a
> part of the client.  Think of browser add-ons/plugins/extensions.
> Client side scripts could (read might be, could possibly, needs further
> thought, etc.) be given permission to be loaded in by worn items
> automatically.  Other objects would likely need to request permission via a
> security warning.
> Client extensions would have to be downloaded and installed externally; not
> delivered in-world.  These would truly be programs on your computer, and
> should be treated as such.
> Just my thoughts hoping for a clearer discussion.
> Ricky
> Cron Stardust
___
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

Re: [opensource-dev] Client-side scripting in Snowglobe

[Edward Artaud]

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  wrote:
> Maggie Leber (sl: Maggie Darwin) wrote:
>>
>> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud 
>> 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