[opensource-dev] Client-side scripting in Snowglobe

[Morgaine]

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