[opensource-dev] Client-side scripting in Snowglobe

[k\o\w]

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 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 
> <mailto: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
>     <mailto: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
>
>
>
>
>
> _______________________________________________
> 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/588df2cc/attachment-0001.htm