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 <s...@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 <s...@lindenlab.com> wrote: > On Fri, Mar 12, 2010 at 9:34 AM, Morgaine > <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
