I'll try to answer your question, Tateru. Judging by the only two facts that have been been divulged to us (Mono, and sandbox), it seems a reasonable *guess* (important word) that they're intending to support distributed CLR binaries that run "safely" (important quotes) in a sandbox, and hence cannot interface to any user facilities outside of the sandbox.
As will be clear to even the most modest of "power users", this is wholly inadequate on numerous fronts, which I enumerated in the thread starter article. It doesn't support the most important aspect of client-side scripting by far, which is to empower the user in any way she sees fit through full-power local scripting, often interfacing to local facilities which cannot be done from a sandbox. Supporting accessibility requires this. The choice of Mono/CLR is also inadequate, for reasons already given, but it gets worse. Mono in the client should have Lindens screaming away in horror, given the support nightmare that this will create. This will be a major new language subsystem to fail, with bugs arising for every binding that they will have to support. It contrasts extremely badly with the comparatively tiny task of supporting some API functions and callbacks plus a very small socket interface. It's just my guess though. And that's the travesty of this. Why the blazes is a major design for an open source viewer, in a project expressly set up to foster cooperation with the open source community, being done in secret? Why do we have to guess? Why is this not being designed with the community, openly, in the same spirit as they expect the community to help them find and fix bugs? It's really not right. Morgaine. ======================================= On Sat, Feb 20, 2010 at 3:06 AM, Tateru Nino <tateru.n...@gmail.com> wrote: > Okay, so which one of these is the Lab thinking about, then? That'll > settle a lot of debate right there. > > On 20/02/2010 2:00 PM, Argent Stonecutter wrote: > > On 2010-02-19, at 01:16, Ricky wrote: > > > > > >> I suspect that there are two things being discussed here without > >> distinction: Client scripting, and client extensions. Confusing the > >> two is easy. > >> > >> Client-side scripting SHOULD be sandboxed, and in a controlled set > >> of languages. For a close example think of javascript in web > >> browsers. > >> > >> Client extensions, or alternatively named as "plugins", would be > >> modules that can be plugged in and out of the client and run /as if/ > >> they were a part of the client. Think of browser add-ons/plugins/ > >> extensions. > >> > >> Client side scripts could (read might be, could possibly, needs > >> further thought, etc.) be given permission to be loaded in by worn > >> items automatically. Other objects would likely need to request > >> permission via a security warning. > >> > >> Client extensions would have to be downloaded and installed > >> externally; not delivered in-world. These would truly be programs > >> on your computer, and should be treated as such. > >> > >> Just my thoughts hoping for a clearer discussion. > >> > > A very good summary. Thank you. > > > > _______________________________________________ > > 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 > > > > > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > _______________________________________________ > 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 >
_______________________________________________ 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
