[opensource-dev] Client-side scripting in Snowglobe

Morgaine morgaine.dinova at googlemail.com
Fri Feb 19 16:34:17 PST 2010


That's not a good choice of terms, Latif, as it doesn't distinguish between
the two cases:  one in which the script is untrusted and hence sandboxed,
and the other in which the script is trusted and can freely hook into
platform facilities.


On Fri, Feb 19, 2010 at 11:14 PM, Latif Khalifa <latifer at streamgrid.net>wrote:

> People seem to be confusing two different things: client side
> scripting, and client extensions or plugins.
>
> 1. Client side scripting
>
>
Both our cases use scripts, and in both cases the scripts run client-side.
Therefore both cases are examples of *client-side scripting*.  This is not a
good phrase for distinguishing between the two cases.



> Think web browsers. They all support execution of client side scripts
> in one language in sandboxed environment. So the way original post
> describes proposed design for client side scripting fits neatly in
> this scenario.
>
> Having a unified platform that scripts can depend on existing in the
> client (say viewer 2.3 and up support it) would allow all sort of new
> and innovative content to be created.
>
> 2. Plugins
>
>
"Plugin" denotes a mechanism for adding some programmed functionality, but
that applies to both our cases.  Plugins can be autoloaded on demand, and if
they're untrusted and run in a sandbox then this doesn't even need any user
confirmation.  Again, this mechanism word doesn't distinguish between the
untrusted+sandboxed case and the trusted one.  Both could be implemented as
plugins, and the word really means too many things to help us.  For example,
plugins that load into the host application address space are common, but
plugins that run in a separate process are also available, and becoming more
common because of multicore.  This word doesn't help us disambiguate our two
cases.



> Think Firefox extensions/plugins. Like Flash, Java applets, etc. This
> is entirely different concept. In-world content cannot depend on these
> being present, and have to allow for situation where  some users have
> some plugins installed, while other do not.
>
> Both of these concepts would be a welcome addition to the viewer. I
> would imagine that the needed internal changes to the viewer could be,
> at least partially, used for implementation of both. If the first step
> is to implement client side scripting as described above, we should be
> talking about it, and separate plugin discussion into a different
> thread.
>



While I think we both agree on the nature of the two cases, it seems hard to
find good labels to describe them concisely yet correctly. :-)


Morgaine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/3eebc4ed/attachment-0001.htm 


More information about the opensource-dev mailing list