Argent Stonecutter wrote: > On 2010-02-19, at 12:53, Robin Cornelius wrote: > >> Well Morgaine's socket based idea could over come this very easily. If >> the API was exposed via a socket, LL could provide a plugin loader >> much as they do for the MediaAPI now, if they want, this pluginloader >> could be CLR based and the default LL implementation of plugins could >> be mono assemblies. So the plugin loader could be directly used by any >> language that can produce CLR binaries. >> > > I suggested a socket based extension mechanism some years ago and was > knocked down because you couldn't do things that required high > performance access to textures, shaders, and so on. If that overhead > is acceptable, then the socket mechanism would be completely language- > agnostic, and it might even act as a legal firewall between the GPLed > client and extensions. > >
"Socket" can be another term for "IPC" in this context. I can create a shared memory buffer using FFI calls in squeak, then draw to it using squeak calls to OPenGL. Same would apply using pure smalltalk drawing commands. The next step is to grab the shared buffer that the SL media plugin API creates and draw to that instead. At that point, anything drawn via squeak becomes a local SL texture ala the media plugin. Share those drawing commands between squeak instances over the internet and you have automatic updates to any participating client in a collaborative whiteboard scenario (any OOP object in squeak can be based off of TObject instead of Object, so the full P2P collaborative semantics of croquet can be used for anythign from a full blown virtual world, to a single realtime drawing on the side of a SL prim). For efficiency with people who don't need collaboration you can instead-of/in-addition-to stream the updated texture to a quicktime or other media server and use the current SL mechanisms to show a read-only version of your whiteboarded texture ala html/QT on a prim. Same would apply for any other kind of collaboration from building to scripting to sculpties to [fill in the blank with something no-one has thought of yet]. Variations of this strategy using other collaborative services and languages besides squeak smalltalk could be used instead of/in addition to. I'm just prototyping things in squeak because of the realtime nature of smalltalk development plus the already existing resources that exist in the TeaTime P2P client-server architecture as implemented in croquet. So "socket" IS being embraced officially in the SnowGlobe client via the media plugin (there is provision in the plugin design for mouse/keyboard events to be sent to/from the plugin via genuine socket IPC rather than shared memory) and the model can be extended as above to handle literally ANYTHING if you want to, assuming the internal events/API are exposed to the outside world. Morgaine and I advocate that EVERYTHING be exposed in principle with sandboxing done via registration of external event handlers on a per-plugin basis. By default every event handler permission is turned off, and you must both manually install the plugin and enable it to register event handlers using some currently undefined process (check boxes/white lists/etc) that the plugins can't bypass. This gives scripting languages and plugins the ability, in theory, to modify the behavior of the client in literally any conceivable way as long as the event handlers are explicitly enabled. "Events" might include raw packets ala what can be injected via gridproxy, or GUI events (button press/mouse movement) or human-like commands (teleport to new world/sim ) or physics calculations or new kinds of IM messaging or custom building controls, etc., etc. Adding entirely new features might require a lower level access which may or may not be scriptable, but client-side "scripting" at the level Morgaine and I are talking about can interact with literally any existing function and blur the distinction between "scripting" and many plugins. As to how these events are handled internally, and whether or not some language framework (mono/.net) is given a first amongst peers status, that's another question, but what *I* am hoping for is that the external socket/IPC/plugin interface be given a first class citizenship, even if there's an extra layer for non CLR languages and systems. And smalltalk syntax may work with the CLR, but the smalltalk IDE is incompatible with CLR, so there must be a level of indirection for a smalltalk based plugin to work. Lawson Lawson Lawson _______________________________________________ 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
