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

Morgaine morgaine.dinova at googlemail.com
Sun Feb 21 20:51:20 PST 2010


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


Morgaine.





===========================================

On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol <dzonatas at gmail.com> wrote:

> Morgaine wrote:
>
>> Carlo, I agree completely with you on the principle of the implementation.
>>
>> 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 "Odd."
>
> 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
> sphere.
>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100222/69ec4baf/attachment-0001.htm 


More information about the opensource-dev mailing list