[opensource-dev] Known details of LL 'Firefly' client-side scripting

[Morgaine]

Soft, I answered your post (enclosed below) quickly on Friday 12th to
correct the unfortunate misreading of the words I had written, as that was
rather urgent.  I didn't have time then to answer your point about our
technical discussions with Q though, as it needed the details to be dug out.

Now I'll deal with the specifics of the Linden client-side scripting work,
because this is where you invited "well-backed positions".  Hopefully you
will see that our position is very well backed, because it is based on the
information that we were given at Linden OH.


On Fri, Mar 12, 2010 at 6:10 PM, Soft Linden <soft at lindenlab.com> wrote:

> I don't know the details of this work.
>
>
Whereas OH attendees do know the details, to the extent that they have been
revealed to us, so I'll provide this same information for you and others to
see.  Then we can refer back to the reasons why we need to revisit the
Linden design decision.



> I'm pretty sure you've also sat in on Q's office hours more than once.
> What did he say when you asked about plugin decisions there?
>


I have indeed sat in on these, more than once, and this is why I know enough
about it to be able to make the comments I made earlier.

I have my chat log for the OH of 3rd Feb 2010 open in front of me, just to
be sure that I am not misremembering anything.  Although the discussion
contained an hour-long rejection of virtually all critical input, it was
also quite informative regarding the *general* nature of the 'Firefly'
project, so I'll summarize for you the technical details as accurately as I
can, using the original Linden words (shown in quotes) and little else.  The
following was spread out over an hour:


   - "We ARE working on client-side scripting; there's a project just
   getting underway. It will NOT be a 2.1 sort of  thing, it's a pretty big
   project."
   - "My goal is to create a platform for plugin UI development with a
   completely open API specification, built on an open scripting platform
   (almost certainly mono)", "capable of doing anything that the viewer
   protocols are capable of."
   - "The viewer that incorporates this scripting platform will be BUILT in
   the scripting language."
   - "It needs to have a solid sandbox model (therefore Mono or another
   robust VM) and a strong, capabilities-based security model."
   - "Each plugin should be required to request specific caps based on
   need.  In its metadata, it has to say what caps it's going to need.  Any
   attempt to request other capabilities at runtime is rejected, the VM sandbox
   can control its abilities."
   - The goal is to provide "a model in which people can trust a plugin."
   - "There are two layers -- the viewer has a scripting platform and our
   viewer at least will attempt to prevent requesting the cap. The cap itself,
   however, is issued by the server."
   - "Anything the client can do manually will be possible" [for a script as
   well].
   - "This means automation, bots, and accessibility will all be MUCH
   easier."
   - "The flip side of this, as morgaine is pointing out, is that we have a
   lot more hardening to do to regulate access at our servers."
   - "We shouldn't have to rely on a well-behaved client."
   - "Sai, you're correct. There are some caps which would be client-side
   only."
   - "CPU, what it means is that a plugin that wants to do that has to
   advertise -- on installation -- that it wants to do that. I'm guessing there
   won't be much of a market for such plugins."
   - "And we might decide to restrict access to such a cap to a signed
   plugin, through a dev api or something."
   - "The developer platform discussion is still under discussion."
   - "What babbage is saying is the idea of distributing some inworld
   scripts to the client."  "That's part of the motivation of using Mono
   client-side."



The hour also featured a large amount of discussion about CLR-based
languages, all of it predicated on Mono being the single mandatory route to
client-side scripting, and clearly indicating that any other language
programming would have to go through Mono.

Although the above is rather skeletal, it is very clear as far as it goes.
It leaves little doubt about how Firefly is intended to work, namely as I
described in my reply to Rob Nelson:  *a mechanism for running untrusted
binaries on user's computers automatically*.  None of this was made up, it
was based on the information given to us by a Linden, and it is on that
basis that we have been making our objections.  Given more information we
could of course make a more detailed analysis, but this is the best we can
do when the rest is a secret.

You will note that the binaries run in a sandbox (although the proposal is
highly confused about sandboxes, since it talks about installation), and
consequently this system cannot be used for programming viewer extensions
which interface to user-chosen local resources because this would compromise
or break the sandbox.  It represents the "*untrusted not-installed sandboxed
world extension*" type of plugin mechanism that I have described
previously<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000173.html>,
as opposed to the "*trusted installed non-sandboxed viewer extension*" type
represented by, for example, Firefox extensions.

It is the latter type (viewer extensions) that has gained almost unanimous
support on this list because of the major user empowerment that it would
provide.  Therefore your design simply does not meet the single biggest
community requirement.

Your design is also *not language agnostic*, thus alienating a large
proportion of extension writers, and it almost certainly *requires
Mono*which alienates another large portion, and it also adds a huge
overhead and
an unnecessary dependency to an already over-bloated and memory-hungry
viewer.  (If the goal is a completely new viewer then the objections are
slightly different but still of the same nature, as well as adding the huge
issue of where it leaves Snowglobe.)

The problems with this approach were described in much more detail at the start
of the client-side scripting
thread<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000088.html>back
in February, in calm, collected, and technical language, and the
length
of the resulting thread highlighted the massive community interest in this,
with barely any community disagreement except on terminology.  We even
provided a couple of simple use
cases<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000137.html>for
illustrating<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000143.html>basic
required functionality, just to make clear that interfacing to local
resources is crucial.  All of this input was either ignored or dismissed,
and even the goal of cooperation was rejected from one Linden quarter.

Our objections are very well backed --- they are based on details supplied
by Lindens, examined as best we can through the veil of secrecy about design
motivations.

What more do you want us to do?  The next logical engineering step is our
technical re-evaluation of your current design together with Lindens,
because the design as presented does not fulfill very important community
requirements.  Yet you reject all our attempts at such normal engineering
cooperation.

It is not for want of polite and analytic effort on our part that
discussions have been going nowhere.  We have tried very hard to take a
normal engineering route, and if you sense frustration from us it is because
we detect a non-responsive party on  the other end of the Snowglobe
partnership.

I hope the above meets your test of a "well backed position".  Please
reciprocate now with a *well-backed justification* of your design for
client-side scripting, given that on current evidence, it fails in numerous
ways to address the requirements that the open source viewer community has
expressed so far.


Morgaine.





====================================

On Fri, Mar 12, 2010 at 6:10 PM, Soft Linden <soft at lindenlab.com> wrote:

> On Fri, Mar 12, 2010 at 9:34 AM, Morgaine
> <morgaine.dinova at googlemail.com> wrote:
> >
> > Virtually nobody other than Lindens are "hellbent on binary plugins", and
> > Lindens are doing so in secret in order not to have to justify themselves
> to
> > the community.
>
> I don't know the details of this work. I do know that ascribing these
> kinds of motives instead of asking "why" questions is a good way to
> get yourself written off as a hurdle instead of a resource. That later
> rhetoric about "sociopaths" and some of the earlier comments make it
> clear that input is going to be unpleasant and ultimately
> counterproductive. If you read back over your message, could you see
> the outcome being a dev going out of the way to involve you in their
> work?
>
> Civil, objective discussion with well-backed positions would signal
> that the community's going to be a resource that can make a Linden
> more productive in his work. Where that's the case, they would be nuts
> not to go to the list as soon as possible. But colored as the list has
> been, I know I wouldn't even want to talk more than I had to about a
> Snowglobe-specific change. It would just get in the way of getting
> things done.
>
> I'm pretty sure you've also sat in on Q's office hours more than once.
> What did he say when you asked about plugin decisions there? I expect
> he'd have answered with something other than psychopathy and
> conspiracy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100317/c893ed96/attachment-0001.htm