Re: [opensource-dev] Client side scripting.

The hard part isn't coming up with an embedded scripting language, it's not even coming up with a secure set of bindings that don't allow for unanticipated side-effects or privilege escalation, it's integrating the scripting engine into an event loop that wasn't designed to have a scripting engi

Re: [opensource-dev] Client side scripting.

I Am going to put together a test build this week with it and see what it can do and how well it works. On Sun, Sep 12, 2010 at 8:39 PM, Ricky wrote: > Hehe, client-side scripting has been in the works for a while now. At > least one dev has a working model, (Dzonatas Sol in SNOW-375 I > believ

Re: [opensource-dev] Client side scripting.

Hehe, client-side scripting has been in the works for a while now. At least one dev has a working model, (Dzonatas Sol in SNOW-375 I believe,) and there has been loads of discussion on the idea on this very forum. Just got interrupted by one of the many "big" events that's happened since mid-Marc

[opensource-dev] Client side scripting.

Was looking at this it would be really simple and really powerful including new ui's and stuff. You could expose what llclass methods you want and create new ones. Wrap that up into a mono dll that they just use the name space of so they dont have to bother with any extern code syntax. http://www

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

It's an architectural style to allow programs to communicate with stateless packets, internally or externally. For example, an HTTP client/server is a logical implementation of a REST design. Unlike the SOAP style, methods are uniform and resources follow a pattern. Please review the dissertati

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

Heyas Dzonatas, nice work. I think this approach needs serious consideration. Perhaps you can be so friendly as to explain to the list what defines REST, and why this approach is a RESTfull implementation? On Wed, Mar 17, 2010 at 10:21:06AM -0700, Dzonatas Sol wrote: > Here is a sample of the RES

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

WGET is part of linux. It should also be available on Windows: http://gnuwin32.sourceforge.net/packages/wget.htm To compile, you can try these instructions: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Communicator It compiles on Windows, but I don't distribute a binary -- just the patch.

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

..Except they seem to be instructions for a command-line operating system? ?_? - Nexii On Thu, Mar 18, 2010 at 12:04 AM, Nexii Malthus wrote: > Very cool Dzonatas! > > Now If only I could get snowglobe to compile, I'll try out OpenSource > Obscure's build instructions as well. > > - Nexii > > >

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

Very cool Dzonatas! Now If only I could get snowglobe to compile, I'll try out OpenSource Obscure's build instructions as well. - Nexii On Wed, Mar 17, 2010 at 7:58 PM, Dzonatas Sol wrote: > Thank you. I've tried to keep it simple and minimal for everybody. > > For example: > > $ wget http://l

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

Thank you. I've tried to keep it simple and minimal for everybody. For example: $ wget http://localhost:50140/Agent/Groups ... etc Earlier today I considered a way to keep a passive connection open, so that one can easily access the viewer from shell scripts. It's not hard for me to re-enabl

Re: [opensource-dev] Client-side scripting REST/HTTP doc sample

That looks very neat! SNOW-375 talks a lot about the MonoVida viewer, but I don't see any mention of that in your email below. Is MonoVida needed to try this out? I'm interested in just poking at the REST interface a bit with some raw http. I'll see if Opensource Obscure's build instructions on

[opensource-dev] Client-side scripting REST/HTTP doc sample

Here is a sample of the REST/HTTP doc for SNOW-375. SNOW-375 adds a HTTP server in the viewer to be easily accessible by any process or client-side script in a language agnostic manner. I posted this here to hopefully encourage forward movement in client-side scripting and to avoid the backpeda

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

On 2010-02-22, at 03:13, Tigro Spottystripes wrote: > the other day i was reading about how the Unreal engine works, they > have > the client predicting the physics and sending control events tot he > server. During a lag spike the client continues to simulate the motion > by itself, and then whe

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 the other day i was reading about how the Unreal engine works, they have the client predicting the physics and sending control events tot he server. During a lag spike the client continues to simulate the motion by itself, and then whent he server star

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

It is really sad. When people in the open source community have dedicated there life to help build open source products for the viewer suddenly find out that Linden Lab has totally ignored all that work already put into projects done by the open source community. Consider that I have personall

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

On 2010-02-20, at 19:37, Morgaine wrote: > > It is interesting to hear that you also had this kind of > communications architecture in mind. I think perhaps it's an > applications model whose time has finally arrived, the age of > multicore. It's a fairly natural model. It was really first

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

Argent, I'll just add one specific point to Lawson's broader treatment. In the fully factored out Multi-Process Client designthat we were working on back in the days when AWG did such things, the various processes were attached by

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

Thanks Kitty for that correction. :-) Accurate naming and attribution may not be world-shattering issues, but that's no reason for getting them wrong, and I am glad you took the time to put the record straight. :D /me waves to Kitty and Marine :-) Morgaine. ==

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

Thank you Kitty, I appreciate it :) On 20 February 2010 15:36, Kitty wrote: > >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-define

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. Slight little corre

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

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] Client-side scripting in Snowglobe

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 example think of javascript in web browsers. Client exte

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

B-B-But what about Lua, which has already been implemented in FlexLife (http://flexlife.nexisonline.net)? :( Fred Rookstown Lead Developer On Thu, 2010-02-18 at 12:42 +, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers.

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

On 2/18/10 7:57 AM, Kent Quirk (Q Linden) wrote: > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list

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

On Thu, Feb 18, 2010 at 5:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: >> >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting persona

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

On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > To me, an environment such as SL or the web in general tend to attract a > few malicious developers, or more so, companies and individuals who are > interested in collecting personal data and usage patterns. I'd prefer some > level of contro

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

I haven't been following this topic in any office hours so I hope my comments aren't too off base. Personally I'd prefer to be able to run extensions as sandboxed, and maybe have the option of running them unprotected on a per-extension basis. To me, an environment such as SL or the web in general

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

OK. I get it. You like fanning the fires of flame wars. Very funny. Mike k\o\w wrote: > I for one agree with Q. The biggest complaints come from the most > insignificant people. If LL prioritized development based on the > complaints in this mailing list, they would be rewriting SL for Linux

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

On Thursday 18 February 2010 17:57:52 Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seem

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

I for one agree with Q. The biggest complaints come from the most insignificant people. If LL prioritized development based on the complaints in this mailing list, they would be rewriting SL for Linux using GTK and maintaining a dozen branches for ever popular flavour of unix. But then we'd jus

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

On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden) wrote: > This makes me sad. There's lots to be sad about. I think current Linden Research policies regarding viewer design and development has severely damaged the trust relationship that should exist within an open-source developer commun

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

Kent, it is true that Office Hour discussions can sometimes get a bit heated because of the format, which allows little time for careful consideration and reflection before writing, but that is not the case here. My opening post above was polite and factual, and it considered all the points that h

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

If you were trying to have an open discussion, then you went about it quite wrong. Nothing was mentioned on this mailing list. I don't think anything was mentioned in the Open Source Meeting (which has of late become nothing more than a Snowglobe bug triage) and I don't see any transcripts on

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

My suggestion would be to in cases where policies and such are being decided that LL not have an office hour (or a couple office hours) but an office DAY and yes im suggesting that a linden or lindens put in a full 12 hour time where folks can discuss the subject. Even if Y'all did it tag team sty

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

On Thu, Feb 18, 2010 at 10:57:52AM -0500, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues in > my office hours, specifically to understand the constraints and requirements > of > the community. But every office hour

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

This makes me sad. I've been trying to have an open discussion about some of the design issues in my office hours, specifically to understand the constraints and requirements of the community. But every office hour seems to be followed up by flames on this list and in other forums interpreting

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

ilto:margaret.le...@gmail.com] On > Behalf Of Maggie Leber (sl: Maggie Darwin) > Sent: Thursday, 18 February 2010 6:35 AM > To: Frisby, Adam > Cc: Argent Stonecutter; Morgaine; opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > On

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

On Thu, Feb 18, 2010 at 9:06 AM, Frisby, Adam wrote: > From what I understand, Mono ended up implementing a lot of that for > Silverlight; although I do not know how the security holds up compared to the > official .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on > Windows.

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

y 2010 5:46 AM > To: Morgaine > Cc: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > 7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't > eyeball them. Creating a sandbox is a huge, complex, and dif

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

On Thu, Feb 18, 2010 at 8:45 AM, Argent Stonecutter wrote: > Java and Mono/.NET intermediate language can do anything native code can... Quibble: I can't speak for the MSFT-proprietary platforms, but Java code runs subject to the classloader's SecurityManager. I do hear talk that Silverlight is

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

7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't eyeball them. Creating a sandbox is a huge, complex, and difficult job, even in an application designed to run untrusted content from the ground up. Putting a blind scripting environment inside something like the SL client

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

On Thu, Feb 18, 2010 at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers.  This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design

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

A line got lost from my post owing to finger trouble. Item 6 about Mono should have read: 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, requiring Mono for client-side scripting would make scripting unavailable to that portion of t

[opensource-dev] Client-side scripting in Snowglobe

I referred recently to Linden's internal project "Firefly" to add client-side scripting to SL viewers. This has been the topic of open discussion at several Office Hours with Lindens in SL, but that openness has not extended to many design details --- the Firefly design process is not open to the