Re: [opensource-dev] Client-side scripting in Snowglobe

Argent Stonecutter wrote: > On 2010-02-19, at 12:53, Robin Cornelius wrote: > >> Well Morgaine's socket based idea could over come this very easily. If >> the API was exposed via a socket, LL could provide a plugin loader >> much as they do for the MediaAPI now, if they want, this pluginloader >

Re: [opensource-dev] Client-side scripting in Snowglobe

I'll try to answer your question, Tateru. Judging by the only two facts that have been been divulged to us (Mono, and sandbox), it seems a reasonable *guess* (important word) that they're intending to support distributed CLR binaries that run "safely" (important quotes) in a sandbox, and hence can

Re: [opensource-dev] Client-side scripting in Snowglobe

On 2010-02-19, at 18:51, Rob Nelson wrote: > My main problem with Socket-based thing is that it opens up all > kinds of > problems, ranging from outside apps screwing with the socket and doing > stuff that the user has not authorized, If the socket is bound to 127.0.0.1 then only applications

Re: [opensource-dev] Client-side scripting in Snowglobe

On 2010-02-19, at 12:53, Robin Cornelius wrote: > Well Morgaine's socket based idea could over come this very easily. If > the API was exposed via a socket, LL could provide a plugin loader > much as they do for the MediaAPI now, if they want, this pluginloader > could be CLR based and the default

Re: [opensource-dev] Client-side scripting in Snowglobe

Okay, so which one of these is the Lab thinking about, then? That'll settle a lot of debate right there. On 20/02/2010 2:00 PM, Argent Stonecutter wrote: > On 2010-02-19, at 01:16, Ricky wrote: > > >> I suspect that there are two things being discussed here without >> distinction: Client scri

Re: [opensource-dev] Client-side scripting in Snowglobe

On 2010-02-19, at 01:16, Ricky wrote: > I suspect that there are two things being discussed here without > distinction: Client scripting, and client extensions. Confusing the > two is easy. > > Client-side scripting SHOULD be sandboxed, and in a controlled set > of languages. For a close

Re: [opensource-dev] Client-side scripting in Snowglobe

> and this is where languages like perl/python have a strength since the > files are plain text > so if you think that a script is doing something funky you can just > look at the script and see. Mono/dotnet code is compiled and very > easily could hide just about anything. I think using anything

Re: [opensource-dev] Client-side scripting in Snowglobe

Morgaine wrote: > No Edward, client-side scripting is not related to in-world scripting > at all. It's scripting OF THE CLIENT, and it has the sole purpose of > extending the functionality of the client, on a personal basis. > > While it's nice to hypothesize about in-world scripts being > off-

Re: [opensource-dev] Client-side scripting in Snowglobe

Mike Monkowski wrote: > Client-side scripts can only operate on data that is client-side. It > means that they do not operated directly on in-world objects. They only > access the client's representation of those objects. Any actions > performed by a client-side script would only be visible t

Re: [opensource-dev] Client-side scripting in Snowglobe

According to the latest Emerald change log they've removed LUA altogether. Regardless of where the scripts are executed, I think it's safe to assume that LL will deliver a robust, well protected system that provides very limited (but very useful) access to the viewer and thus minimizes exploit

Re: [opensource-dev] Client-side scripting in Snowglobe

My main problem with Socket-based thing is that it opens up all kinds of problems, ranging from outside apps screwing with the socket and doing stuff that the user has not authorized, to simple security concerns (I'm sure as hell going to trust a readable Lua/LSL/shell/anything-other-than-LISP scri

Re: [opensource-dev] Client-side scripting in Snowglobe

That's not a good choice of terms, Latif, as it doesn't distinguish between the two cases: one in which the script is untrusted and hence sandboxed, and the other in which the script is trusted and can freely hook into platform facilities. On Fri, Feb 19, 2010 at 11:14 PM, Latif Khalifa wrote:

Re: [opensource-dev] Client-side scripting in Snowglobe

When I think of client-side scripting for the viewer, I'm definitely thinking of the latter, not the former. Inworld objects sending limited scripted tasks to the viewer? Doesn't even seem all that useful or desirable, though surely there must be *some* use-cases. On the other hand, being able to

Re: [opensource-dev] Client-side scripting in Snowglobe

People seem to be confusing two different things: client side scripting, and client extensions or plugins. 1. Client side scripting Think web browsers. They all support execution of client side scripts in one language in sandboxed environment. So the way original post describes proposed design fo

Re: [opensource-dev] Client-side scripting in Snowglobe

No Edward, client-side scripting is not related to in-world scripting at all. It's scripting OF THE CLIENT, and it has the sole purpose of extending the functionality of the client, on a personal basis. While it's nice to hypothesize about in-world scripts being off-loadable to the client, that i

Re: [opensource-dev] Client-side scripting in Snowglobe

Client-side scripts can only operate on data that is client-side. It means that they do not operated directly on in-world objects. They only access the client's representation of those objects. Any actions performed by a client-side script would only be visible to that particular client. So

Re: [opensource-dev] Client-side scripting in Snowglobe

I'm certainly not against a general API for trusted plug-ins (certainly all my emails to this list have been plug-in related), and it would be awesome for tools to be built without everyone having to create a viewer fork. My assumption, however, is that client-side script capability is meant to go

Re: [opensource-dev] Client-side scripting in Snowglobe

The client-side scripts that we are talking about in this thread are not related to in-world LSL scripts in any way. They always execute client-side, isolated in their respective processes, and they only talk directly to the client and sometimes also to local PC resources, such as the text-to-spee

Re: [opensource-dev] Client-side scripting in Snowglobe

Maggie Leber (sl: Maggie Darwin) wrote: > On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud > wrote: > >> For client-side scripts to be something worth >> prioritizing implementing in mainstream viewers, their usage must be >> based on the assumption that some large percentage (80+% maybe) of >>

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin) wrote: > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama > wrote: > > > I'd hope things like attachment sizing scripts would move to client side > > scripts. > > I guess that would be nice, but the data that would have to flow to

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama wrote: > I'd hope things like attachment sizing scripts would move to client side > scripts. I guess that would be nice, but the data that would have to flow to the attached hair prims would be substantialand the prims would still have to be scr

[opensource-dev] Community created interfaces already in use (was: Client-side scripting in Snowglobe)

I guess https://jira.secondlife.com/browse/SNOW-375 is using a similar protocol. cheers Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep un

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, 2010-02-19 at 14:54 -0500, Maggie Leber (sl: Maggie Darwin) wrote: > I was thinking of this as new function, and only incidentally > providing some marginal performance relief for LLs servers in limited > cases...such as how Emerald's avatar radar reduces or eliminates > avatar radar HUDs.

Re: [opensource-dev] Client-side scripting in Snowglobe

RLVa is a very notable user-defined API that has far transcended its original purpose, and is now in extensive use wherever enhancements for accessibility are required. It really highlights how user-defined functionality should have been in the viewer from the beginning. Client-side scripting wil

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud wrote: >  For client-side scripts to be something worth > prioritizing implementing in mainstream viewers, their usage must be > based on the assumption that some large percentage (80+% maybe) of > attachment scripts, for example, would be running cli

Re: [opensource-dev] Client-side scripting in Snowglobe

Smartest point made on the topic, and it really makes sense to stop conflating the two, there are distinct untrusted script and trusted plug-in problems. For client-side scripts to be something worth prioritizing implementing in mainstream viewers, their usage must be based on the assumption that

Re: [opensource-dev] Client-side scripting in Snowglobe

The socket-based approach has the advantages of being OS-platform-neutral, which CLR is not. A JVM-based scripting system leveraging JSR-223 tech would be more platform-neutral, but is certainly not what anybody could call "lightweight". But either of those approaches (as well as others) could be

Re: [opensource-dev] Client-side scripting in Snowglobe

Robin Cornelius wrote: > On Fri, Feb 19, 2010 at 6:40 PM, Lawson English wrote: > >> There's more to a language then just the syntax. CLR-based Smalltalk is >> NOT real smalltalk, for example. >> >> There's no way except perhaps via F# to get something approaching >> smalltalk programming out o

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, Feb 19, 2010 at 6:40 PM, Lawson English wrote: >> > There's more to a language then just the syntax. CLR-based Smalltalk is > NOT real smalltalk, for example. > > There's no way except perhaps via F# to get something approaching > smalltalk programming out of a CLR-based system. > Well Mo

Re: [opensource-dev] Client-side scripting in Snowglobe

Ron Festa wrote: > To be honest the arguments I've been seeing about not using MONO seem > to be forgetting something. There are multiple languages that can be > compiled/interpreted in MONO with the appropriate addon, not just C#. > Just to name a few we have Python, Boo (which resembles Python

Re: [opensource-dev] Client-side scripting in Snowglobe

To be honest the arguments I've been seeing about not using MONO seem to be forgetting something. There are multiple languages that can be compiled/interpreted in MONO with the appropriate addon, not just C#. Just to name a few we have Python, Boo (which resembles Python and seems to come with MONO

Re: [opensource-dev] Client-side scripting in Snowglobe

RLVa, supports something like this, and can be found in most 3rd party viewers: http://rlva.catznip.com/blog/ http://wiki.secondlife.com/wiki/RestrainedLifeAPI On 2/19/2010 10:38 AM, Morgaine wrote: Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course. :-) But here's the

Re: [opensource-dev] Client-side scripting in Snowglobe

Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course. :-) But here's the fun one, for some value of "fun" ... Someone would undoubtedly write an LSL binding to the socket-based API too. And however much we screw up our noses at LSL, I have no doubt that a large number of SL

Re: [opensource-dev] Client-side scripting in Snowglobe

Indeed Rob! Lua is a brilliant language for adding scripting to existing applications --- it's designed expressly for embedding and extending, it has a clean syntax, it is linguistically very powerful, it is very tiny (the whole thing can add under 100KB to your application), it can run sandboxed

Re: [opensource-dev] Client-side scripting in Snowglobe

You can make a plugin part of the process space of its host app or a separate process, it's up to you. The "same process space" architecture is merely the simplest one, and so it's the most common, but now that we're in the age of multicore, that is changing rapidly because it is so easy to harnes

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, Feb 19, 2010 at 01:30:28PM +, Morgaine wrote: > I would avoid your terminology though, because both kinds of script > application > employ "client-side scripting", both types create dynamic "extensions", and > both types can be implemented as "plugins" --- your terms directly describe

Re: [opensource-dev] Client-side scripting in Snowglobe

Ricky, I agree with you, there are indeed two different requirements being discussed here, and confusing them as a single requirement can never yield a satisfactory result. Indeed, Dahlia and I were discussing that same thing yesterday, here

Re: [opensource-dev] Client-side scripting in Snowglobe

On Fri, Feb 19, 2010 at 02:17:17PM +0100, Carlo Wood wrote: > If anything, I admite Q for not falling back to "Sorry, but admire* ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the p

Re: [opensource-dev] Client-side scripting in Snowglobe

On Thu, Feb 18, 2010 at 01:31:43PM -0500, kow wrote: > I for one agree with Q. You're not really stating what you agree with here... but lets assume you mean that: - It's ok that nothing was communicated on this list about anything prior to some decisions made by LL about client-side scripting.

Re: [opensource-dev] step by step guide to compiling snowglobe

On Thu, Feb 18, 2010 at 01:06:54PM -0600, Jonathan Irvin wrote: > As far as SnowGlobe goes, I wish it was more modular like linux goes.  To > where > we can add packages or remove them from the base install to grant us this or > that.  When one module gets updated we can just download it as needed