[opensource-dev] Consensus? was: Client-side scripting in Snowglobe
Carlo Wood
portable, and grid-wide supported downloadable scripts when
talking about Client-side scripting (sorry Morgaine).
So, I propose to go with that, and call anything else
"Client-extensions".
---
The remainder of this post is about Client-extensions.
I sense consensus on the following layered design:
[current code base]
+ lots of hooks to be written
|
|
V
C++ API [1]
|
|
V
IPC API [2]
|
|
V
Plugin(s)
One or more plugins then could provide a client-side
scripting engine; either for trusted for any language,
or a secure API for an engine running the mono bytecode
that LL is working on (or whatever).
- A scripting engine for language XYZ.
[1] Ie, based on the yet to be written LLStateMachine class.
[2] Ie, a socket. What is more important is the protocol
that is being used here. I can imagine that this will
be LLSD, or something simular.
--
Carlo Wood <ca...@alinoe.com>
PS Note that personally I'm against using mono for
clientside scripting...
_______________________________________________
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
Ricky
written as a plugin. Then we'd only have to decide which plugin(s)
get shipped with the client by default. A much more fruitful
discussion I think.
Ricky
Cron Stardust
Maggie Leber (sl: Maggie Darwin)
> Look good to me. As you said, a scripting engine (or three) could be
> written as a plugin. Then we'd only have to decide which plugin(s)
> get shipped with the client by default.
And a well-written JSR-223 plug-in could give you all the JSR-223 Java
scripting languages in one shot.
Morgaine
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:
On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood <ca...@alinoe.com> wrote:
It seems to me that most people still talk about untrusted,
portable, and grid-wide supported downloadable scripts when
talking about Client-side scripting (sorry Morgaine).
So, I propose to go with that, and call anything else
"Client-extensions".
The remainder of this post is about Client-extensions.
...
Plugin(s)
One or more plugins then could provide a client-side
scripting engine; either for trusted for any language,
or a secure API for an engine running the mono bytecode
that LL is working on (or whatever).
And here you've said that Plugin(s) provide a "client-side scripting engine", in other words, an engine that does client-side scripting.
Thank you for showing so clearly that both types are "client-side scripting". :-)))))))
As I've been saying all along, anything that does scripting on the client is "client-side scripting". Any other interpretation is going to confuse the hell out of newbies, and as you've shown yourself, even the experts will not be immune to the confusion it creates. :D
We can of course choose a couple of different words to disambiguate between the two types. That would be useful. I like the phrase "Client Extensions" for the trusted installed scripts a lot! But you can't say that one of them isn't "client-side scripting", when in both cases the scripts run on the client. What's more, those of us who will be writing our extensions will be scripting our clients. You can't eliminate that phrase, it won't work.
I really don't want to belabor this point any further, because it's getting silly.
But on the implementation side, yes, this is a good topic, and you're describing a model similar to the one that Argent and Dzonatas and Sai and I and others have proposed.
Morgaine.
================================
Dzonatas Sol
> 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?
Morgaine
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.
===========================================
Tigro Spottystripes
Hash: SHA1
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
> _______________________________________________
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuCOvEACgkQ8ZFfSrFHsmWb5QCeI7FKwFFU/B42Eo3oDnDa3/2+
cpoAn1yPvCFTv0qFw4y0Ug9yqZr94/bh
=Z9Lb
-----END PGP SIGNATURE-----
Kajikawa Jeremy
Javascript / LindenScript / VBscript / Python,
The source and result program are one and the same,
Client-Side Extensions,
Dynamic Link Libraries / Adobe Flash Player / Java / Mono
The distributed program is NOT the original source
--
Using the former expands on needing security,
Using the latter devolves the client and seperates parts into own
program modules.
An Example of using Both is the Firefox Browser / Thunderbird Email
and similar tools...
Can something similar to that be done?
Use plugins for secure extension of the client from sandboxed scripts?
Dzonatas Sol
> 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.
Carlo Wood
> 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.
This is clearly a way to measure someones spatial insight.
Now note that if it's a game, and coins are not allowed to be moved
around once they are placed, then it's very unlikely that you will
be able to place 6 coins on the surface of that sphere (with diameter
equal to the coin), because the one who'd put down the fifth coin
would not put it such that you can put down the sixth coin, but
somewhere in the middle of the left-over surface, leaving no spot
for the sixth coin. Calling people stupid over this game surprises
me however (because I happen to have a extremely large spatial
insight, officially measured mind you (although, they couldn't
actually graph it in their graph because I scored not just out of
the graph but even off the paper that the graph outline was printed
on)), because I'm having a hardtime to quickly guess if you CAN put
five coins on the sphere... It seems not unlikely that only four
coins will make it... which would mean that the one that begins
will try to leave open as much space as possible when putting
down the third coin. The person to move second would try to use
as much space as possible. So, first goes on top say, second on
grounds of symmetry probably on the bottom, then again forced to
play without any strategy, the third coin just goes on the side,
and the fourth coin, wanting to be last, takes the exact
opposite of that, leaving two places free: Oh hell... that
way you STILL end up with six coins being placed, even though
both tried to screw the other with strategy. The only freedom
that still exists would be the one placing the second coin: by
not placing it exactly on the opposite side, you'll likely end
up with only five coins. However, since putting it on the exact
opposite side caused this player to win, he has little reason
to play it elsewhere. Hence, due to perfect symmetry, the first
player has no real choice, ever. And the second one, who wins,
can control the game completely; hence 6 coins.
Not THAT simple however.
--
Carlo Wood <ca...@alinoe.com>
Carlo Wood
Why not define the words A and B such that A includes B? B \in A
Then you can still talk about the subject, since there is still a C = A \not B,
such that the intersection of B and C is empty.
In other words, yes Client-Extensions include plugins that implement
Client-side scripting, but it won't give confusion because if someone means
that, they will say "Client-side scripting", so if they DON'T say that,
they probably mean something else, either something broader (including
client-side script plugins) or something entirely different even.
On Mon, Feb 22, 2010 at 04:51:20AM +0000, Morgaine wrote:
> 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.
--
Carlo Wood <ca...@alinoe.com>
Colin Kern
There's really no way to figure it out without information about
either of the player's strategies. It seems like what the interview
was really asking is what the maximum number of coins that could be
fit on that surface was, or he should have specified that these two
players were perfect and playing optimally.
Colin
Marine Kelley
are cooperative or in competition. It totally changes the result.
But I guess that the real goal of this challenge is to call you
"stupid" and to gauge your reaction. If you yell or punch the
recruiter, you're dismissed. If you say "my bad, you're right", you're
dismissed. But if you argue and explain your theory clearly, calmly
and with the objective of solving the problem instead of just
defending yourself, you prove that you're someone who can integrate a
team that works on a system that is both technical and social.
Dzonatas Sol
> Exactly my thinking too, the problem us not clear whether the players
> are cooperative or in competition. It totally changes the result.
>
> But I guess that the real goal of this challenge is to call you
> "stupid" and to gauge your reaction. If you yell or punch the
> recruiter, you're dismissed. If you say "my bad, you're right", you're
> dismissed. But if you argue and explain your theory clearly, calmly
> and with the objective of solving the problem instead of just
> defending yourself, you prove that you're someone who can integrate a
> team that works on a system that is both technical and social.
>
>
>
>
Hmm. Let's think about this for a few...
The players are imperfect...
One is the recruiter that knows nothing about the recruitee...
The recruiter calls the recruitee "stupid"
In the reality of the recruitee, kids are missing (as in stolen),
undergoing unknown symptoms of major depression, blisters on feet from
working more than 40 hours a week, on up to 80 hours a week to keep
family together for more than a year, pressured to work more due to
legal problems, almost on the street due to leftover money not meeting
needs, etc etc (this is not made up)
If the recruitor has no knowledge of this, which they shouldn't because
of employment laws, then to call the recruitee "stupid" and for the
recruitee to act any bit calm would be a major ability to stay calm
under such hardship... even if the recruitee just simply said "my bad,
your right" just to pass up an unfair question and explain anything now
going on in the mind of the recruitee.
Major Depression Disorder is a disability that would be exploited by
such question, and this recruitee would never get hired due to this
disability, which is against law to not hire someone because of a
disability.
The reruitee states the obvious and the recruiter takes it as a legal
threat, which questions the ability of how this ever will work as a team
on a system that is both technical and social... where both win.
Long story short... but one is still losing, so when does the "fighting"
stop?
Morgaine
There is no need for A != B.
Why not define the words A and B such that A includes B? B \in A
Then you can still talk about the subject, since there is still a C = A \not B,
such that the intersection of B and C is empty.
For the simple reason that in our case there is no C = A \not B, because A is the set of all scripts that execute client-side, and that includes all the possible types of scripting/programming that we are discussing here: they are all subsets of A.
In other words, yes Client-Extensions include plugins that implement
Client-side scripting, but it won't give confusion because if someone means
that, they will say "Client-side scripting", so if they DON'T say that,
they probably mean something else, either something broader (including
client-side script plugins) or something entirely different even.
It's also normal use of the word "scripting" in numerous language communities --- for example, Lua and Perl and shell programmers always talk about their Lua scripts and Perl scripts and shell scripts, regardless of the application, and it's doubly prevalent when the scripting language is used embedded in a host application because then it distinguishes the script program from the host program. This use of "scripting" is pervasive throughout computing's many language communities.
That's not going to change, so rather than trying to sweep back the tide and stopping people saying that they're doing client-side scripting when they're programming client extensions, it's easier to accept that people will always call scripting "scripting" wherever it is being applied, and invent two new disjoint terms instead.
It's also worth adding to this Tigro Spottystripe's observation that a control panel that provides information and control over script properties, resourcing, protection, and so on, is applicable to all kinds of scripts, regardless of where they come from and what role they play. Even just thinking about such practical areas alone, there is a push for commonality.
It's not even totally black and white that there are two separate categories. One could easily envisage a system where the user controls what local facilities are made accessible to a sandbox per script, so that it's not "all or nothing" like we've been describing up to now. Even trust is not a black and white thing, and nor is installation --- scripts loaded automatically could be cached for longer-lived retention, or even retained forever. Tigro's suggestion is interesting. There really is a continuum here.
Morgaine.
===================================
Carlo Wood
> For the simple reason that in our case there is no C = A \not B, because A is
> the set of all scripts that execute client-side, and that includes all the
> possible types of scripting/programming that we are discussing here: they are
> all subsets of A.
No, A (client-extension) is all plugins, and B (client-side scripting)
is all untrusted client-side scripting.
Morgaine
Morgaine.
============================================