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

Morgaine morgaine.dinova at googlemail.com
Sun Feb 21 14:53:27 PST 2010


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:


On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood <carlo at 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".
>
>
So here you've said that "Client-extensions" are not "Client-side
scripting".  And then you follow that with:


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





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

On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood <carlo at 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.
>
> 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 <carlo at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100221/979c5c8f/attachment.htm 


More information about the opensource-dev mailing list