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

Morgaine morgaine.dinova at googlemail.com
Wed Mar 17 09:17:26 PDT 2010


Mike, Soft was referring to us on the opensource-dev list as a whole.
That's the "we".

As to which "our position" is, that's simply the aggregate of what everyone
has expressed in this list.  People speak for themselves here.

If you're not sure what that "community position" is, you have a lot of
reading to do.  You'll have to start back in February, in the massive thread
that was begun by this post of mine on client-side
scripting<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000088.html>.
The discussion continues, and it's totally open.


Morgaine.




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

On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software) <
mike.dickson at hp.com> wrote:

>  See below for comments..
>
>
>
> *From:* opensource-dev-bounces at lists.secondlife.com [mailto:
> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Morgaine
> *Sent:* Wednesday, March 17, 2010 9:47 AM
> *To:* Soft Linden
> *Cc:* opensource-dev
> *Subject:* [opensource-dev] Known details of LL 'Firefly' client-side
> scripting
>
>
>
> 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.
>
> Morgaine, you use "our position" throughout your message.  It's not clear
> who you're representing when making these comments but I believe based on
> past comments on the list the details are more complex than a simple binary
> LL vs. everyone else. So I'd suggest you either make it clear who you're
> representing with your comments or simply say "I".
>
> [some details removed]
>
>
> 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."
>
> I understand the complexity of an effort like this but ideally I'd prefer
> to see whatever approach is taken implemented in an incremental fashion.  So
> maybe some amount of discussion could be devoted to how to chop up the work
> so it can be done in phases with feedback available after each phase.  Some
> of the media plug-in work was done this way in Snowglobe and I think that
> approach was beneficial.
>
> ·         "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."
>
> I like this approach. The API becomes the inter-module "contract" between
> modules.  You can then feel free to change the underlying implementation as
> long as that contract is observed for a given version of the api.
>
> ·         "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."
>
> I strongly agree with this approach, especially given the goal above to
> code the bulk of the app using the platform.  There are lots of good
> examples of how this can work (Java, Flash/Actionscript, etc).  Installing a
> plugin needs to support the configuration of capabilities that the plugin
> needs to do its work. Again, there are good existing models for that.  This
> ought to support even more complex models where the plugin "proxy" gets the
> capability to start an external process and hook up communications to it
> assuming a grant of appropriate privilege is given.
>
> ·         "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.
>
> I don't follow you here. What I read in the above was a combination of a
> well defined client side extension API and a mechanism to load code that can
> be granted a level of trust based on criteria it needs to do its job.  That
> might include code signing and metadata about the capabilities the client
> plugin needs. I don't see any mention of "untrusted binaries" other than the
> implication that a module that doesn't negotiate additional capabilities
> gets started in a sandboxed environment with minimal capabilities.
>
>
> 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.
>
> Again, I don't follow your conclusions.  If a plugin is granted the
> priviledge needed to start a process or open a socket then there's no reason
> it can't interface to an external program or launch a process it uses to
> provide access to external resources.  IMO, it should do that through a well
> defined API to request such access.   None of that sounds like its at cross
> purposes with the definition that emerges from the chat summary from OH.
>
>
> 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.
>
> Again, I don't see that.
>
>
> 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.)
>
> Assuming a CLR based approach doesn't simply mean C# there are lots of good
> scripting implementations (Lua, Python, Rubs, etc.) available as .NET
> language implementations all of which should be able to be used.   It's
> possible that the sandbox implementation might limit that but I don't see an
> obvious reason it should. Also if this list is too limiting again you can
> install a module that provides a proxy to another environment implemented in
> whatever language you choose.
>
>
> 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.
>
> I guess  I didn't see the same consensus emerge that you're citing.  There
> were a couple of different approaches put forward. And actually really like
> what I've seen of the LL approach to date. As I said, I'd encourage a way to
> prototype implementation of it in phases (using snowglobe2 as a platform,
> for example).  That will maximize opportunity for feedback.  Ideally I'd
> like to see some design notes from LL and a proposed roadmap for how it
> might be implemented.  That would allow folks who wish to do so the ability
> to contribute to the effort.
>
>
> 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, you've adopted an us vs. them position that I don't personally
> feel is necessary.  Nor do I share your opinion that the LL proposals to
> date fail to address any proposals put forward on the list.  Sure its
> possible you don't like **how** it implements them. I guess IMO a better
> approach would be to work together to explore how the proposed approach
> could address requirements and where it falls short or is kludgey discusses
> how those problems could get address (in the context of the LL proposed
> approach).   If someone wants to explore a radically different approach the
> source is available to do that.  I'd personally like to see the list members
> here that are interested  work to evolve the proposed approach put forward
> by LL rather than discuss inventing an alternative approach.
>
> Mike
>
>
>
> 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/b29495c0/attachment-0001.htm 


More information about the opensource-dev mailing list