[opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/f970ce58/attachment.htm