[opensource-dev] Client-side scripting in Snowglobe

[Lawson English]

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