On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood <ca...@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 disjoint terms instead. 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 <ca...@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 <ca...@alinoe.com> >
_______________________________________________ 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
