The socket-based approach has the advantages of being OS-platform-neutral, which CLR is not. A JVM-based scripting system leveraging JSR-223 tech would be more platform-neutral, but is certainly not what anybody could call "lightweight".
But either of those approaches (as well as others) could be implemented up against Morgaine's suggestion, and scriptwriters could choose what dependencies they cared to embrace. I seem to recall not long ago Philip had a project to implement camera-based facial expression recognition whose design included a socket based viewer interface. (Of course, any client-side scripting will face an outcry from certain well-known users who rail against making inherent capabilities of the viewer/server system easier to access or automate as an "invasion of privacy".) I think asking the question "what would you *do* with scripting in the client?" is premature until you identify what client functionality you can or should expose to scripting. This is an issue I'm currently wrestling with in working with Project Wonderland ( http://www.projectwonderland.com ), where the scripting architectures (doesn't have to be restricted to only one implementation) are still essentially greenfields and the underlying architecture is capable of operating both on client and server-side objects. _______________________________________________ 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
