Look good to me. As you said, a scripting engine (or three) could be written as a plugin. Then we'd only have to decide which plugin(s) get shipped with the client by default. A much more fruitful discussion I think.
Ricky Cron Stardust On Sunday, February 21, 2010, Carlo Wood <ca...@alinoe.com> wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > --- > > The remainder of this post is about Client-extensions. > > I sense consensus on the following layered design: > > [current code base] > > + lots of hooks to be written > > | > | > V > > C++ API [1] > > | > | > V > > IPC API [2] > > | > | > V > > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > > - A scripting engine for language XYZ. > > [1] Ie, based on the yet to be written LLStateMachine class. > [2] Ie, a socket. What is more important is the protocol > that is being used here. I can imagine that this will > be LLSD, or something simular. > > -- > Carlo Wood <ca...@alinoe.com> > > PS Note that personally I'm against using mono for > clientside scripting... > > _______________________________________________ > 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
