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