[opensource-dev] Client-side scripting in Snowglobe

Morgaine morgaine.dinova at googlemail.com
Fri Feb 19 20:36:22 PST 2010


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.nino at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/4f718b9d/attachment-0001.htm 


More information about the opensource-dev mailing list