See below for comments.. From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@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 <s...@lindenlab.com<mailto:s...@lindenlab.com>> wrote: On Fri, Mar 12, 2010 at 9:34 AM, Morgaine <morgaine.din...@googlemail.com<mailto:morgaine.din...@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.
_______________________________________________ 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
