[opensource-dev] Consensus? was: Client-side scripting in Snowglobe

Dzonatas Sol dzonatas at gmail.com
Mon Feb 22 12:43:44 PST 2010


Morgaine wrote:
> Dzon:  Nice parable. :-)

Thank you. Unfortunately, some still challenge it as if they know the 
only answer, yet they should read up on Proton Exchange Membranes, 
especially Zero-Emission, for proof.

For a business to use patented method in their employment process was 
quite remarkable.Sometimes people get jurassically blindsided by... scale.


>
> To remove the ambiguity, I split the space of all scripts that run 
> client-side into two disjoint sets (note that we are using "scripts" 
> and "programs" interchangeably here):

I would go with three. Call the third one: "*Transient Scripts & 
**Transient **Array*s", or something similar with the word "transient" 
being significant.More successful designs have included this third area.

Basically, in the transient area, you wouldn't want the responsibility 
of the existence any particular script to fall upon the corporal 
location of such script, not that the corporal is entirely excluded from 
being responsible.There is a balance that is needed, and it is best to 
keep the nature of the balance away from the two other areas you described.

>
>     * *Trusted / Installed / Not-sandboxed*:  These are scripts which
>       you trust enough to install on your machine, and which typically
>       act as interfaces between the viewer and your local resources,
>       such as your files, applications, I/O devices, and so on. 
>       Because they interface to local resources, these scripts cannot
>       run in a sandbox.  In general, these scripts are for user
>       empowerment --- they can do anything the user wants them to do,
>       and therefore a very good term for them is "*client
>       extensions*".   A large number of accessibility scripts fall
>       into this category, as well as scripts for implementing new
>       detached windows such as multi-screen chat and inventories
>       stored on the PC.
>

Good. I would think extensions might confuse what direction they extend 
from, however. If we are to maintain balance, and responsibility, then 
we need to know that direction. The scripts on the client side may have 
nothing to do with the client viewer. These same scripts may also seem 
like a server. Easiest to consider these as "processes," yet that has 
been confused by the organically evolved chipsets and thread technology. 
What the "world" only needs to know from the "world" viewpoint are the 
transfer devices, or membranes. Then we have scripts that can and cannot 
be exchanged through the membrane. Those that can't get through the 
membrane, we call "brains" on one scale and "protons" on another scale. 
That'll work for now.


>
>     * *Untrusted / Not-installed / Sandboxed*:  These are scripts
>       which you do not trust because they arrived by some automatic
>       mechanism, possibly from in-world.  They are never installed,
>       but run in a protective sandbox while needed, and disappear
>       automatically when no longer needed.  Because they run in a
>       sandbox to (hopefully) protect your machine from malicious code,
>       these scripts can never access your local resources, as that
>       would be extremely dangerous.  In general, these scripts are not
>       for user empowerment, but for enhancing or assisting the
>       displayed content from the current virtual world in some way.  A
>       possible term for them is therefore "*world extensions*".  This
>       kind of script can implement interesting HUDs using in-world
>       data obtained from the viewer, or new in-viewer windows, menus
>       and improved viewer inventory.
>
>
>
> A separate question is whether it is wise to allow untrusted scripts 
> to run on your client at all, given that there will always be bugs and 
> protection failures, especially in the first few years.  But that is a 
> topic for a later discussion I think, given that currently we have not 
> yet managed to open a dialogue with Lindens about client-side 
> scripting at all.
That is what the transient area handles.

The only way really possible for completely untrusted scripts and arrays 
to compute on the client side as "world extensions" would be to make a 
complete copy of the original on the other-side of the membrane. That 
isn't always true, yet on the scale of "brains" it's a good idea of 
where to start, not where they would have lost control so easily.

20 years of "fighting" about all this has really set us back.Would have 
been easier if "trust" was actually accepted rather than some paper 
masquerade.




More information about the opensource-dev mailing list