[opensource-dev] Client-side scripting in Snowglobe

Rob Nelson nexisentertainment at gmail.com
Thu Feb 18 21:24:24 PST 2010

B-B-But what about Lua, which has already been implemented in FlexLife
(http://flexlife.nexisonline.net)? :(

Fred Rookstown
Lead Developer

On Thu, 2010-02-18 at 12:42 +0000, Morgaine 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

More information about the opensource-dev mailing list