Argent, I'll just add one specific point to Lawson's broader treatment. In the fully factored out Multi-Process Client design<https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft>that we were working on back in the days when AWG did such things, the various processes were attached by sockets and communicated by messaging because that provides the largest amount of decoupling between modules, harnesses the power of multicore with minimal effort, and avoids almost all the pitfalls of concurrent programming with mutable shared state. It's also easy to debug.
Although local sockets are easily fast enough for the majority of scripting uses within a VW client, there are a few areas where you want to hit the metal at the fastest possible rate, such as rendering. To cater for this, the design allowed "Facility optimization" or "accelerators" to be defined: in most cases this would mean that two communicating processes would negotiate a shared memory segment for their private use, and eliminate any communication bottleneck between them by using direct memory reference. This approach avoids *premature optimization*: you add an accelerator to a socket link only when profiling tells you that a particular task is suffering from socket throughput or latency issues. In addition, it provides a reference model for functionality: your accelerator should modify only the *speed* of interactions between two processes, and not the semantics. Any unit tests that worked through sockets alone should continue to work with the accelerator enabled, just faster. Transparent acceleration gives you a huge development win. That said, the Multi-Process Client is only vaguely related to the design that we're discussing for client-side scripting in this thread. The viewer is not being redesigned from scratch (as far as we know), and hence a full decomposition along these lines is not in the realm of possibilities. Instead, we have in mind a rather minimalist messaging interface within the viewer, the bare minimum that would allow a message sent by a scripting process to activate a function in the viewer, plus the inverse operation, viewer callbacks that respond to viewer events by sending a message to any script process interested in the event. Despite the minimalism, it is worth noting that the "accelerator" approach of the Multi-Process Client still applies here. There is no reason why an attached script process could not open a dedicated shared memory segment and cooperate with the viewer in very high speed operations, including graphics rendering. It is interesting to hear that you also had this kind of communications architecture in mind. I think perhaps it's an applications model whose time has finally arrived, the age of multicore. Morgaine. ================================= On Sat, Feb 20, 2010 at 6:27 AM, Lawson English <lengli...@cox.net> wrote: > 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 >
_______________________________________________ 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
