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. _______________________________________________ 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
