[opensource-dev] Client-side scripting in Snowglobe

Morgaine morgaine.dinova at googlemail.com
Fri Feb 19 06:41:56 PST 2010


You can make a plugin part of the process space of its host app or a
separate process, it's up to you.  The "same process space" architecture is
merely the simplest one, and so it's the most common, but now that we're in
the age of multicore, that is changing rapidly because it is so easy to
harness more cores with separate processes, and it avoids the many pitfalls
of concurrent thread programming with shared state.

When separate processes are used for plugins (typically communicating with
the host via socket), they can be either totally disjoint or they can share
one or memory segments, the term is quite generic.  When we were designing
the client-side scripting plugins for Imprudence, we used the separate
process space architecture<http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png>.
  LL uses the same approach in their media plugins (Plugin-API), they're
external to the host viewer as well.  This is going to become a very common
architecture for plugins, in part because of the strong safety and security
of process separation.  Internal or external is really an implementation
detail for plugins.

Since plugin systems of both types are in common use, the term "plugin" is
not useful to us when differentiating between *trusted* scripts and *
untrusted* scripts.  (Sandboxes can be in internal memory space or external
process space too.)  At this stage we're just trying to raise a discussion
with Lindens about the two quite distinct requirements, trusted and
untrusted, both of which are extremely important and both of which need to
be supported.

Discussing the process design architecture will be highly interesting and
important too of course, but it's all rather academic if we can't get
Lindens to even discuss the requirements.  While I appreciate your earlier
suggestion that Snowglobe could go independent if community needs are not
met, I have not yet lost hope that Lindens will decide to work with the open
source community on client-side scripting.

It's only day #2 of this after all. :-)


Morgaine.




=======================================

On Fri, Feb 19, 2010 at 1:50 PM, Carlo Wood <carlo at alinoe.com> wrote:

> On Fri, Feb 19, 2010 at 01:30:28PM +0000, Morgaine wrote:
> > I would avoid your terminology though, because both kinds of script
> application
> > employ "client-side scripting", both types create dynamic "extensions",
>  and
> > both types can be implemented as "plugins" --- your terms directly
> describe the
> > technologies that can be used in both types of application and don't
> > distinguish between the two differing requirements.  It would just add to
> the
> > confusion.
>
> Plugins are inheritly unsafe and will have access to anything a normal
> process has. If client-side scripting is going to be provided on a plugin
> with the same access to the system, then it's still a plugin.
>
> Hence, I see no problem talking about "plugins" for "trusted" applications
> and not even mention scripting in that case (for now).
>
> Then we can reserve the word client-side-scripting for third party /
> downloaded scripts.
>
> --
> Carlo Wood <carlo at alinoe.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/1b0fbf94/attachment.htm 


More information about the opensource-dev mailing list