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 <ca...@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 <ca...@alinoe.com> >
_______________________________________________ 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
