Carlo, both you and Morgain make very good arguments as to why various parts I separated are, technically, the same. However, while I understand that Dynamic Scripts (loaded from serverside) and UserScripts are completely the same thing (just like in a browser, the JavaScript loaded from the server-side alongside the web page, and GreaseMonkey UserScripts are both just seperate views of the same thing,) they are made distinct in the terminology here due to the fact that a user will see a difference.
I also understand how you would see the Extensions and Plugins as also being nothing but the same thing. Setting up an IPC layer in the C++ is absolutely required, but I don't think that we need to put /multiple/ ways of connecting plugins into the code hooks. I'd prefer the most direct method of using a form of dynamically loaded shared library that implements a common object Interface that the client then calls. This provides the most direct, most capable interface. It is also not very abstract, as the underlying code could easily change in such a way as to break the interface, but that is a common enough problem for any of the plugin designs I've met with. As I mentioned before, one of the first of these plugins could easily be one that exposes a socket based interface for a more abstracted system, a la Morgaine's design. Note that while most users may not explicitly notice a difference between Plugins and Extensions, as they can easily blur use-cases, they are hugely different in the back-end. Consider Plugins to be ways of writing a "patch" that provides a new feature to the client. Extensions could do the same, but are out on a distinct abstraction layer provided by a variety of plugins. For Dynamic scripts and UserScripts users will see a distinct boundary, even though there is no such boundary in the back-end. One is for the server-side coder to do things to my client, while the other is a way for me to easily do things to my client. Again, these can be provided by various plugins/extensions. And while I put no sandbox restriction upon the Plugins, that shouldn't be considered to mean that the plugin designer couldn't decide to sandbox their own code. I'd love to see the Shared Media re-factored into a plugin that provides a sandboxed environment for connecting to and displaying the media. One big point there is that with these different layers of capability, there could exist a free market of competing Plugins, competing Extensions, Dynamic scripts providing more engaging interaction while reducing server load, and easy customizability with UserScripts. Each has its purpose, and each has its userbase. I know my dad, who is a fairly good scripter, would not be interested in writing a plugin or extension, but would love to be able to write dynamic client scripts. I'd love to have the opportunity to dig as deep as I'd like in the code, but to be able to start in a much cleaner environment, such as implementing a plugin, or even easier, an extension. They would be much cleaner to build than a patch, and easier to distribute! Ricky On Sun, Mar 7, 2010 at 6:20 AM, Carlo Wood <ca...@alinoe.com> wrote: > On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote: > > Client Plugins > > Ok, although I'd prefer if-- for example-- media plugins run in a sandbox; > think about the recent mention of the quicktime exploit. > > > Client Extensions - Interpreted code packages placed in a special folder > in the > > client directory by the user/admin of the client's installation. > > These should run in a broad sandbox: Limited local disk access (max > datastore > > size, etc.) to a special file in the local user folder. Eg: > ~/.secondlife/ > > slfirst_lastname/extensions/extensionname.eds (Extension DataStore) But > can > > still access much the same client hooks as the Plugins. > > Provides fast prototyping, and lower entry difficulty, than Plugins, but > will > > most likely not have the freedom to tap into a lot of system stuff. Also > will > > not typically run as fast or in as little memory space as the binary > plugins. > > > Dynamic Client Scripts - Interpreted scripts loaded from the server via > the > > server-side permissions system. > > Since this and Client Extensions are both interpreted code, these are > basically the same-- just with different permissions. I don't think we > should at this point make a difference between scripts based on their > source or permissions, but only based on their implementation layer. > > > May still need a better name... > > Could be stored in Notecards and a server-side script could petition, > via > > llRequestPermissions, to be able to request that the client download the > > notecard named via a llLoadClientScript(string name, integer channel) or > > similar command. The notecard would then be downloaded by the client and > the > > plugins/extensions that had registered as able to interpret scripts would > then > > be queried as to their ability to understand the code, and the one that > > answered with the most certainty could be given the task. Some sort of > > first-line header in the notecard would help this process along. > > This deals with where the code comes from, not how it runs. > > > Executed within TIGHT sandboxing: Limited, or no access to local disk > > storage, and limited to tasks such as drawing on the HUD layer of the > GUI, > > creating floaters to draw in, communicating back to the world via the > > predefined channel number, etc. The limits are, of course, up to the > plugin/ > > extension maker. Another potential limit would be the automatic > unloading of > > the script when the host object is out of range, or is no longer > attached. Of > > course the Plugin maker could decide when, or if, the user should be > asked > > before loading the script, even if the server-side has given its > permission. > > In other words, Client Extensions-- but with more restrictions (less > permissions). > > ... > > UserScripts (Term borrowed from GreaseMonkey) - Interpreted scripts > loaded > > dynamically into the client by the user. > > Function just like Dynamic Client Scripts, except the source is the > user > > themselves opening a local text file, or opening a console window and > typing > > commands. > > Provides local quick changes, and even personal > never-touched-the-server HUD > > objects, floaters, etc. Lowest entry difficulty of the whole set of > ideas. > > The implementation of this is still the same, just even less permissions. > No? > > In terms of layers (one thing build ON TOP of another), we have, imho: > > SNOW-553 (C++ hooks; LLStateMachine) > | > V > Inter Process Communication (IPC) support (C++; sockets; serialization) > | > V > Plugins > | > V > Client Extensions (including Dynamic Client Scripts, User Scripts etc). > > -- > 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
