[opensource-dev] Client-side scripting in Snowglobe

Rob Nelson nexisentertainment at gmail.com
Fri Feb 19 16:51:45 PST 2010


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 script more than a binary
executable or shared library), to platform issues (opening local
listeners may piss off certain software firewall implementations), not
to mention the sheer amount of data that must be converted to and from
UDP/TCP and transferred over a connection, which could cause latency.  

Having an embedded scripting engine is simply easier for script-writers,
too.  All a user needs to know is what functions to use and where to put
the sourcecode, whereas a socket-based solution means that a networking
API must be present, and the user must maintain a constant connection to
SL's process, requiring them to either have a provided API that supports
their language (consider the sheer amount of maintenance this would
require), or have TCP/IP experience and functions.

I'm all for having a way to dynamically load a scripting engine
DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets
in order to interface with their client.  There are other ways that
aren't as risky, complex, and laggy, and trust me, I'm having enough
trouble integrating Lua with SL.  The huge level of maintenance and
dependency-juggling that just two language APIs would present could
overwhelm even the Emerald dev team.

On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote:
> 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> 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
> >                 
> >                 
> >                 
> >         
> >         
> > 
> > 
> > _______________________________________________
> > 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




More information about the opensource-dev mailing list