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 users who know no other language would be very happy to see it. :-) Providing a socket-based interface to the viewer would be a hugely all-embracing approach to client-side scripting, supporting everyone's needs. I think it deserves consideration. Morgaine. =================================== On Fri, Feb 19, 2010 at 3:23 PM, Morgaine <morgaine.din...@googlemail.com>wrote: > 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 or not as > desired, and it is one of the fastest pure scripting languages currently > available, a lot faster than say Python. > > It is no surprise then that game developers worldwide flocked to it in > droves, and now it's one of the most common scripting languages found > embedded in games. WoW fans use it daily as an intrinsic part of their WoW > client, and a huge community has grown up around Lua-powered interfaces for > that game. > > So yes, I'm with you on the importance of Lua for client-side scripting of > the viewer. > > However, advocating Lua as the sole means of scripting viewers would be > just as bad a mistake as advocating C# or CLR-targetted languages only. It > would support only one part of the scripting community directly, while > discriminating against everyone else. This is not necessary. > > Instead, defining a socket-based API interface would allow effectively any > language to be used for scripting the viewer, since virtually all languages > today have socket capabilities. That would certainly include Lua and C# and > Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk, > to name a few languages that this community uses regularly. > > The only thing that we would have to agree on would be the set of messages > that cross the socket interface, and the set of functions and callbacks that > the messages would engage in the viewer. That's the kind of productive > technical discussion we could be having with Lindens, if their design > process for client-side scripting were open. It needs to be. > > > Morgaine. > > > > > > =========================== > > > On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson > <nexisentertainm...@gmail.com>wrote: > >> 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 +0000, 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 details --- the Firefly >> > design process is not open to the community. The only technical >> > details that are being disclosed about Firefly appear to be: >> > >> > * "Scripts" are actually Mono assemblies, so that only languages >> > that compile to Mono will be allowed. >> > * The programs run in a sandbox, which means that most platform >> > resources are not accessible to them. >> > >> > Please note that I quite like C# as a language, but the following >> > remarks are about Mono use in the SL viewer, only, where its tradeoffs >> > are poor. >> > >> > The first known detail about Firefly (mandatory Mono) is problematic >> > on several fronts: >> > 1. Only a tiny fraction of the world's applications, libraries >> > and languages work on Mono, so client-side scripting will be >> > unable to benefit from the huge mountain of resources >> > available on the Internet. This is an extremely severe >> > limitation, and an unnecessary restriction in the context of >> > client-side viewer scripting. If I want to use a >> > locally-installed package X from within my client-side script, >> > I should be able to. What runs client-side should always be >> > our individual choice, not someone else's. >> > 2. Programmers want to write client-side scripts in the language >> > that they know best, because that always yields the fastest >> > progress and highest quality results. There was a good >> > technical reason for forcing everyone to use LSL server-side, >> > but there is no technical reason to impose this requirement on >> > all client-side scripting. It is counter-productive to force >> > CLR compatibility on client-side script developers when there >> > is a simple alternative: define a socket-based viewer API for >> > client-side scripts instead, hence usable from any language. >> > 3. Mono runs poorly on Linux, so from being rock-solid on Linux >> > now, the LL-derived viewers will become second-rate on this >> > platform. >> > 4. The viewer is already extremely bloated and a memory hog. >> > Adding a Mono dependency will compound that horribly. >> > 5. There is only one effective supplier of Mono: Novell. That >> > is a very bad situation to encourage and to support in the >> > viewer. >> > 6. Some parties identify other reasons for avoiding Mono in >> > general. Without getting into that subject at all, >> > >> > The second known detail about Firefly (mandatory sandbox) is >> > problematic on two related fronts: >> > 1. Sandboxes by design do not allow most platform resources to be >> > accessed, as a security measure. This is fine and important >> > when scripts are being downloaded from unknown places (like >> > Javascript in web pages), but that same protection also means >> > that client-side scripts would be powerless to do useful >> > things for us in concert with local applications, files, >> > devices, etc. Sandboxing client-side scripts effectively >> > hardwires in script weakness for no reason discussed as a >> > requirement. >> > 2. Sandboxed applications cannot be linked with user-chosen >> > native libraries since allowing native code breaks sandbox >> > protection. This means no accelerators, no extensions, and no >> > interop with other systems since sockets are inaccessible from >> > any strong sandbox. This also means no evolution or progress >> > outside of what the sandbox designers permit. >> > >> > This mailing list is concerned with development of open source >> > viewers, in particular Snowglobe. This is heralded as a community >> > viewer, embodying community requirements much more directly than the >> > LL mainstream viewer. Client-side scripting will impact on every >> > single aspect of Snowglobe bar none, yet the community is being >> > excluded from the design of its most powerful infrastructure element. >> > This is entirely wrong, far beyond the normal observation >> > that secrecy in design has no place in open source. >> > >> > It is hard to assess things technically when the design requirements >> > are formulated in secret. The Snowglobe community has design >> > requirements too. Those deserve to be examined here openly, not >> > limiting Snowglobe to a design that stems from Linden requirements >> > alone. >> > >> > >> > Morgaine. >> > >> > _______________________________________________ >> > 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 >> >> >> >
_______________________________________________ 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
