[opensource-dev] Client-side scripting in Snowglobe
kow at sapinski.com
Fri Feb 19 07:47:51 PST 2010
RLVa, supports something like this, and can be found in most 3rd party
On 2/19/2010 10:38 AM, Morgaine wrote:
> 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.
> 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.
> 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
> (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
> > that compile to Mono will be allowed.
> > * The programs run in a sandbox, which means that most
> > resources are not accessible to them.
> > Please note that I quite like C# as a language, but the
> > remarks are about Mono use in the SL viewer, only, where its
> > are poor.
> > The first known detail about Firefly (mandatory Mono) is
> > on several fronts:
> > 1. Only a tiny fraction of the world's applications,
> > 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
> > that they know best, because that always yields the
> > progress and highest quality results. There was a good
> > technical reason for forcing everyone to use LSL
> > 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
> > 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
> > 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
> > when scripts are being downloaded from unknown
> places (like
> 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
> > 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
> > 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
> > 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
> > viewer, embodying community requirements much more directly
> than the
> > LL mainstream viewer. Client-side scripting will impact on
> > single aspect of Snowglobe bar none, yet the community is being
> > excluded from the design of its most powerful infrastructure
> > 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
> > 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
> > 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:
> Please read the policies before posting to keep unmoderated posting privileges
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev