A line got lost from my post owing to finger trouble. Item 6 about Mono should have read:
6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, requiring Mono for client-side scripting would make scripting unavailable to that portion of the user base. Since client-side scripting without Mono is perfectly feasible, Mono should not be made mandatory for scripting, so that the widest user base can be supported. Morgaine. ======================== On Thu, Feb 18, 2010 at 12:42 PM, Morgaine <morgaine.din...@googlemail.com>wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community. The only technical details that are being disclosed > about Firefly appear to be: > > > - "Scripts" are actually *Mono assemblies*, so that only languages that > compile to Mono will be allowed. > - The programs run in a *sandbox*, which means that most platform > resources are not accessible to them. > > > Please note that I quite like C# as a language, but the following remarks > are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > > 1. Only a tiny fraction of the world's applications, libraries and > languages work on Mono, so client-side scripting will be unable to benefit > from the huge mountain of resources available on the Internet. This is an > extremely severe limitation, and an unnecessary restriction in the context > of client-side viewer scripting. If I want to use a locally-installed > package X from within my client-side script, I should be able to. What > runs > client-side should always be our individual choice, not someone else's. > 2. Programmers want to write client-side scripts in the language that > they know best, because that always yields the fastest progress and highest > quality results. There was a good technical reason for forcing everyone to > use LSL server-side, but there is no technical reason to impose this > requirement on all client-side scripting. It is counter-productive to > force > CLR compatibility on client-side script developers when there is a simple > alternative: define a *socket-based viewer API* for client-side > scripts instead, hence usable from any language. > 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, > the LL-derived viewers will become second-rate on this platform. > 4. The viewer is already extremely bloated and a memory hog. Adding a > Mono dependency will compound that horribly. > 5. There is only one effective supplier of Mono: Novell. That is a > very bad situation to encourage and to support in the viewer. > 6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, > > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > > 1. Sandboxes by design do not allow most platform resources to be > accessed, as a security measure. This is fine and important when scripts > are being downloaded from unknown places (like Javascript in web pages), > but > that same protection also means that client-side scripts would be powerless > to do useful things for us in concert with local applications, files, > devices, etc. Sandboxing client-side scripts effectively hardwires in > script weakness for no reason discussed as a requirement. > 2. Sandboxed applications cannot be linked with user-chosen native > libraries since allowing native code breaks sandbox protection. This means > no accelerators, no extensions, and no interop with other systems since > sockets are inaccessible from any strong sandbox. This also means no > evolution or progress outside of what the sandbox designers permit. > > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a *community* viewer, embodying > *community* requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a > design that stems from Linden requirements alone. > > > 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
