Mike, with reference to CLR and languages (I'm trying to partition the discussion into manageable chunks, so only one topic at a time):
On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software) < mike.dick...@hp.com> wrote: > > Assuming a CLR based approach doesn't simply mean C# there are lots of > good scripting implementations (Lua, Python, Rubs, etc.) available as .NET > language implementations all of which should be able to be used. It's > possible that the sandbox implementation might limit that but I don't see an > obvious reason it should. Also if this list is too limiting again you can > install a module that provides a proxy to another environment implemented in > whatever language you choose. > > You're missing two key points here. The first is that reimplementing a language on top of an existing runtime is not the same thing as being able to use a language natively. Languages are implemented with specific runtimes for very good technical reasons, and shoehorning them into another framework's VM model is almost guaranteed to deny essential facilities from operating. For example, you mention Lua, which I use quite a lot. Lua is designed expressly for use in embedding and extending arbitrary applications through its C/C++ API. If Lua is re-implemented afresh on top of another CLR language, it loses that native ability entirely. Alternatively, if the existing Lua implementation in ANSI C is linked into the CLR runtime directly, then the C/C++ interface is still available but it would have to be denied as it would break the sandbox. Either way, Lua scripting would no longer benefit from the masses of add-ons available in the Lua community, virtually all of which are implemented as native extensions. A bigger issue though is simply not being language agnostic in the first place. This totally misses the opportunity of harnessing people's skills in dozens or hundreds of languages that are not available for CLR, using their favorite IDEs and other tools. It denies them the benefit of the huge number of libraries out there in other languages, representing thousands of man years of effort. Restricting the languages available for *sim-side* scripting made sense, because that's an environment that Lindens need to control. But that requirement does not apply to client-side scripting of extensions, which are about *user control and empowerment*, not LL's. If there were no other solution, then fine. But there are other solutions. Over the 2+ years of AWG, we have examined in quite some depth how to create language-agnostic interfaces (mostly with the viewer in mind), and it's not particularly hard. I've detailed one clean approach here in various posts since February -- namely, using a socket API so that any language whatsoever could use the API from an external process, with no language-specific programming nor bloat in the viewer. The benefits of doing this are colossal (I've listed them in prior threads), while the disadvantages are really minor, mostly that it takes more effort to reach bare metal speeds. Given such a language-agnostic approach, the sky is really the limit, because quite literally anything is possible in external processes written in arbitrary languages, without being imprisoned in a sandbox that has to be made leaky for interfacing and hence is necessarily compromised. All the specialist languages for concurrency or artificial intelligence or scientific simulation can be brought to bear directly. The result would be quite astounding. So there *ARE* alternatives, and they don't have the problems with the embedded Mono approach that several of us have described here over the last 4-5 weeks. Finally, your suggestion to use a proxy is just a bandaid on top of an inherent design fault, which is the hardwiring in of one scripting runtime into the viewer in the first place. It is not necessary, and it imposes too many restrictions with only an illusion of security, not to mention creating a maintenance nightmare for the viewer. If we can get client-side scripting to be discussed with Lindens openly, these pro's and con's will be brought into the light of day, and then we can see how the balance tips in terms of engineering benefits, objectively. And that's my purpose in raising the matter. Design done in secret avoids objective assessment. Morgaine.
_______________________________________________ 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
