Ricky, there's nothing major wrong with your classification, but you make two breakdowns which actually have no clear demarcation between them:
- Your "Client Plugins" and your "Client Extensions" are actually one and the same thing, merely representing two different use cases of the same mechanism. You're trying to distinguish between compiled languages and interpreted languages, which used to make sense in the past. Nowadays, however, all decent scripting / interpreted languages are actually compiled internally (often even having a JIT compiler), and compiled languages are commonly compiled to bytecode rather than to native machine code, so it's largely a matter of presentation in today's world. And a "broad sandbox" makes no actual sense --- if local platform facilities are made available in a sandbox then it's a sandbox with dangerous holes, which rather misses the point of having a sandbox for platform protection. This category of client-side scripts or programs really does not fit the sandboxed model at all. - Your "Dynamic Client Scripts" and your "UserScripts" are one and the same thing too, because the only distinction you make between them is where they come from, which is not a significant distinction in the actual implementation. While we're here eliding distinctions though, it's worth pointing out that sandboxed client-side scripting is easily implemented within a mechanism for non-sandboxed client-side scripting, but not the other way around! This is why Linden's sekrit Firefly project is so completely wrong. Once you have a *client extension* type of mechanism, adding a sandbox within the extension is quite simple, while vice versa it is actually impossible because a working sandbox denies access to local facilities. You would have to punch holes in the sandbox and hence compromise it (a very bad idea), and the choice of languages would be severely constrained for no reason. It would be a dreadful design choice, and not meet the requirements of a highly empowering client-side extension mechanism. Morgaine. ========================================= On Sun, Mar 7, 2010 at 7:19 AM, Ricky <kf6...@gmail.com> wrote: > A while back, before the 2.0 announce interrupted our conversation, I had > made a post about what I saw as three different forms of client-side > scripting/plugins/whathaveyou. I've since been convinced that I missed > something. > > So here goes again, with a (hopefully) improved set of definitions: > > Client Plugins - Binaries compiled per-platform and placed in a special > folder in the client directory by the user/admin of the client's > installation. > These should have no security restrictions, and should have access to any > file on your computer that the system allows, and access to any internal > process of the client. > Provides the ability to build parts of the client without recompiling: > eg. Client-side script interpreters, better joystick support, expose further > public APIs via sockets or whatever, etc. > Also is free to access system libraries, such as OpenGL, windowing > toolkits, etc. > > 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. > 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. > 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. > Provides the ability to make advanced HUDs, radars, etc. These would > mostly eliminate the need for object-based HUDs, improving server speed by > taking non-content load off the server, and still allow the specialized > groups in SL the ability to create HUDs and tools that users could be given > automatically upon entering a "role-play" area. > > 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. > > > Note that should the Client Plugins be implemented, all the rest, and more, > could and would be implemented in droves. Also any security restrictions, > or lack thereof, would be created by the plugin designer. The above > security restrictions would then be only guidelines. > > These seem to cover the whole range of what has been discussed so far. > Morgaine's interpreted client scripts/plugins communicating via sockets > would be considered Client Extensions and would be implemented starting with > a really generic Client Plugin. This is assuming that I've understood > Morgaine's idea correctly! :) > > Yes, I've been mulling this over and over in my brain since the previous > conversation was interrupted.... I had just gotten to the point where I was > enjoying the back and forth of problem solving! > > Ricky > Cron Stardust > > _______________________________________________ > 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 >
_______________________________________________ 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
