RLVa is a very notable user-defined API that has far transcended its original purpose, and is now in extensive use wherever enhancements for accessibility are required. It really highlights how user-defined functionality should have been in the viewer from the beginning.
Client-side scripting will undoubtedly take accessibility to the next level, and I would fully expect RLV itself to become a common binding for many client-side scripting languages. Accessibility provides many good examples to illustrate how client-side scripting would work over a socket-based API in the viewer. Let's look at a simple example that is of huge interest and benefit not only to the visually impaired but to anyone who doesn't particularly enjoy reading scrolling text: ----------------------------- SIMPLE TALKER SCRIPT 1) The user either executes the talker script manually (just like any conventional program), or else the script launches automatically on viewer startup, or else the script is launched from the viewer's script manager if there is one. If there are special accessibility issues to consider, this step can be complicated, and tailored to the individual needs of the user. 2) The script immediately connects to a predefined port on the same machine as the viewer, on which the viewer is listening for incoming script connections. The viewer's connection listener accepts the connection and sets up the appropriate TCP channel and messaging command interface for communicating with the script. 3) The script sends the viewer a message to register a callback for the NewCommunicateTabOpened event, in order to be notified of new channels of communication appearing in the viewer. 4) The viewer registers the callback for this script. (Note that any number of attached scripts could register interest in the same callback.) 5) Someone starts a personal IM to this user or sends an IM to one of the user's groups, and a new Communications tab pops up in the viewer. Since the script has registered for the corresponding event, a message of the appropriate type and naming the channel that has just appeared is sent by the viewer to the script through the socket. 6) The script responds to the incoming event, and sends back a message to register a callback for the ChatMessageReceived event, parametrized with N, the number of old chat messages desired (1, if only the message that opened the chat tab is wanted). 7) The viewer registers the callback and sends the requested N chat lines, one per message of the appropriate type, parametrized with the channel identifier and carrying the chat line as payload. The types could be different for personal and group IM, vicinity chat, system messages, etc. 8) The script receives each incoming chat event message and sends it to the local text-to-speech program on the user's machine, which could be a commercial package or an open source one such as Festival. Note that the script could apply transformations to each line to increase listenability, including assigning gender or tiny voices as desired, or filtering out undesired types of message such as graphic spam. 9) When no more chat talking is desired, the script can simply be killed. The viewer will note the TCP socket closing and will remove all registered callbacks for this script and tidy up appropriately. END ----- It is very important to note that client-side scripts written for accessibility purposes are very often interfaces to local resources or applications, and cannot be sandboxed, since those resources or applications would not be accessible from within a strong-walled sandbox. This is why a sandboxed CLR environment is not enough for a generic client-side scripting system --- it doesn't meet a very large set of crucial use cases. Both sandboxed and not sandboxed script environments are required, to cater for untrusted and trusted scripts respectively. Morgaine. =========================================== On Fri, Feb 19, 2010 at 3:47 PM, k\o\w <k...@sapinski.com> 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.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 >> > 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 >
_______________________________________________ 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
