[opensource-dev] Client-side scripting in Snowglobe

[Dzonatas Sol]

It is really sad.

When people in the open source community have dedicated there life to 
help build open source products for the viewer suddenly find out that 
Linden Lab has totally ignored all that work already put into projects 
done by the open source community.

Consider that I have personally logged the idea of client-side scripting 
back in April 2007: http://jira.secondlife.com/browse/SVC-98

I find it hard to believe that LL wouldn't want to work with anybody 
that has done such work. Since I don't want to believe that, then what 
conclusion can we come to if LL continues to leave us out in the cold. 
It appears as if LL takes the ideas under their wing, but only the idea. 
When will LL also take up those that obviously have the idea and have 
already spent a lot of time invested in this that would be a solid 
benefit to LL to have them on the team.

For LL to completely do it from scratch without the others means even a 
greater cost to the investors of LL. It means LL employees has to spends 
the hours of time to comes up with the exact same design conclusions 
that we have come up with already. Obviously our attempt to join the 
team at LL isn't anything about being not productive, we just think it 
saves the investors money on productivity we've already done.

I would like to contact the investors of Linden Lab and ask them 
personally their decision on the matter.

Dz

Kent Quirk (Q Linden) wrote:
> This makes me sad.
>
> I've been trying to have an open discussion about some of the design 
> issues in my office hours, specifically to understand the constraints 
> and requirements of the community. But every office hour seems to be 
> followed up by flames on this list and in other forums interpreting 
> what was said in the worst possible way.  
>
> I'm afraid the tone and direction of this discussion are making it 
> impossible for us to talk about this project productively.
>
> Q
>
>
> On Feb 18, 2010, at 7:42 AM, 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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