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
