[opensource-dev] Client-side scripting in Snowglobe

Morgaine morgaine.dinova at googlemail.com
Fri Feb 19 07:38:10 PST 2010


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.dinova at 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 <nexisentertainment at 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/8a530a71/attachment.htm 


More information about the opensource-dev mailing list