[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