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

Mike Dickson mike.dickson at hp.com
Wed Mar 17 09:34:36 PDT 2010


On 03/17/2010 11:17 AM, Morgaine wrote:
> 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.
That's really my point. I wrote because your response doesn't represent
my own position and I felt that I was potentially being lumped into the
"our" category.  And I re-read Soft's original message and I don't see
"we" or "us" mentioned. It looked to me like he was simply stating that
making impassioned arguments that drift towards the emotional are
counter-productive and likely to get ignored.  Again, that sounds pretty
reasonable to me. And very understandable.
>
> 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.
I did in fact read the entire thread and again, I don't agree that the
"community position" is that clear cut. Certainly not as binary as
you've painted it.  I saw lots of relevant points made from different
positions.  My personal perspective is that I'd like to see what LL has
put forward implemented, ideally in phases and as much in the open as
possible.  I accept that others may not agree with ot but I haven't
personally seen an example that *can't* be done with the LL model though
ideally there'd be a test bed to try out things as proof points either way.

Mike

>
>
> Morgaine.
>
>
>
>
> ================================
>
> On Wed, Mar 17, 2010 at 4:01 PM, Dickson, Mike (ISS Software)
> <mike.dickson at hp.com <mailto: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>
>     [mailto: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
>     <mailto:soft at lindenlab.com>> wrote:
>
>     On Fri, Mar 12, 2010 at 9:34 AM, Morgaine
>     <morgaine.dinova at googlemail.com
>     <mailto: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/5a0cab68/attachment-0001.htm 


More information about the opensource-dev mailing list