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.din...@googlemail.com
<mailto: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
<mailto: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
_______________________________________________
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
