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
