[opensource-dev] Consensus? was: Client-side scripting in Snowglobe
tigrospottystripes at gmail.com
Mon Feb 22 00:06:32 PST 2010
-----BEGIN PGP SIGNED MESSAGE-----
i think that instead of separating the scripts, we should have a table
with script names, some info, like creator etc, and a bunch of
checkboxes to give or deny permission for the script to do stuff, with a
way for client scripts to trigger a permission request dialog. Among the
permissions would be a permission to remember permissions, and another
to save the script locally/with the account.
On 22/2/2010 01:51, Morgaine wrote:
> Dzon: Nice parable. :-)
> The moral of the story as it pertains to our topic is that when the
> superset is ambiguous as in our case (all scripts running client-side
> are naturally "client-side scripts"), then the ambiguity won't stop
> until you subset the space into disjoint subsets so that you can discuss
> each subset separately without confusion.
> That's what I've been trying to do, because "client-side script" is a
> universal term that naturally denotes all scripts running in the client
> by simple plain English, so you can't call just one subset of the
> scripts by that name without creating ambiguity.
> 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):
> * *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.
> * *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
> 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.
> On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol <dzonatas at gmail.com
> <mailto:dzonatas at gmail.com>> wrote:
> Morgaine wrote:
> Carlo, I agree completely with you on the principle of the
> On the terminology, not only are you not being logical in your
> naming, but you also immediately contradict yourself and
> demonstrate beautifully how your suggested naming makes no sense
> at all, not even to yourself.� Let me demonstrate:
> One of Linden Lab's disqualifiers on attempts to be hired had to do
> with a coin placed on any surface and the game of prediction of who
> would win based on who placed the last coin on the surface where
> there was room left over.
> They go through a bunch of different kinds of objects, so I won't
> name them off so they can still use the fair ones.
> However, there was one they were beautifully wrong about: the sphere.
> They even called people "stupid" on the spot who couldn't figure out
> the sphere ended up with even amount of moves. Long story short
> about... stupid.
> We could challenge this since somehow it became more than personal,
> or maybe it was meant to be challenged eventually. It wasn't their
> standard procedure whatever it was.
> If we take a perfect sphere with a perfect surface, there is an
> obvious flaw that wouldn't allow it to be even in number of moves.
> When LL said "here is a sphere the size of a quarter in diameter...
> 1 2 3 4 5 6" as one points top, bottom, left, right, back, front.
> And says "Stupid" with a superiority look.
> Obviously the person that was challenged, the one to be hired, said
> If you know if it is "even" or "odd" then you know who gets the last
> move, and wins.
> Further on the surface about a perfect sphere, if it diameter is
> perfect no matter what tangent coordinate picked out on the surface,
> then the surface could be eventually said it is infinite. There
> would be infinite possibilities of any location on the surface that
> could be tangent coordinated.
> If that is true, which gave the possibility of infinite surface,
> then one could also put another perfect sphere nearby the first
> perfect sphere.
> Here is the beauty of this, if the first perfect sphere has an
> infinite surface and the second perfect sphere has an infinite
> surface, then they are both the same infinite surface.
> The rules of this game never specified where to put the next perfect
> Now if left some space in between the two spheres, then it should
> still be "Even" number of moves if we continue with this one.
> What we put the sphere tangent or in union with the first one. It's
> the same surface, and the game was about the surface.
> If it is plainly tangent, then there would be one less coin to put
> on the surface, and it would be "Odd."
> No? Not convinced, yet? You say that would be two less coins? And
> you claim "Even?"
> Let's add another perfect sphere...
> Same infinite surface.
> When do we stop?
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting privileges
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the opensource-dev