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

Tue Feb 23 07:10:55 PST 2010

On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood <carlo at alinoe.com> wrote:

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

Except that there is no possibility of avoiding confusion your way, because
when people write scripts that execute in the client, they will unavoidably
call it client-side scripting.  It's totally unavoidable because it's normal
use of English.

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

It's also worth adding to this Tigro Spottystripe's
observation<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000175.html>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.

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

On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood <carlo at alinoe.com> wrote:

> 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.
>
> 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 <carlo at alinoe.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/d8ecd142/attachment.htm