[sldev] Client-side scripting is real (was: Script memory limits, promises, parcel bonus)

[Carlo Wood]

I've thought about such an API in the past a bit, and my idea
was to have an interface that takes XML "messages" (char strings
thus, basically).

The viewer would provide a socket (or whatever, a function call
would do too if it's possible to link with it) and read incoming
messages, decode them and do whatever they say.

The other way around there needs to be information going from
the viewer to whatever wants to interface with it. Also this
should be in the form of XML messages.

The reason that XML should be used is so that it is easy to
extend, without breaking existing "clients": you can later
add an argument or data, and not not confuse the interpreter
of the XML messages. Also, you can first implement a certain
set of messages, for example to control the UI, and later
add another set of messages, for example to control the
avatar, etc.

What do you think of this basic idea behind this? Lots of
details need to be worked out still of course, I think we
can already decide that in the end the lowest level of
comunication will be XML messages.

On Wed, Dec 23, 2009 at 07:56:18AM -0800, Dzonatas Sol wrote:
> We need a standard API for to this to work well. I wouldn't expect a 
> formalized standard to happen quickly, but an API no doubt is needed at 
> least.
> 
> We can treat the network code now in the viewers as part of the Agent 
> Domain. It probably didn't appear like that before, yet with the API it 
> certainly does.
> 
> I guess some didn't take an API seriously because they thought it 
> disabled or prevented user interfaces already present in the viewer.
> 
> This show that an API doesn't disable or prevent any user interfaces 
> already present in the viewer:
> http://jira.secondlife.com/browse/SNOW-375
> 
> As the API develops into a more truer RESTful scheme, then client-side 
> scripts could run in each of there own process without the need to be a 
> directly plugged into one another (or compiled together). This is a very 
> scalable approach. Here, the network code acts in the viewer acts as a 
> hub for the Agent Domain (a subset of it until more formal).
> 
> If you look at the code for the World Map, the viewer updates the script 
> of the position, but then the map uses HTTP to fetch the textures. Even 
> without any code being disabled/prevented in the viewer, you can expect 
> that the viewer would not have to chew on texture fetches, which would 
> mean more time it can spend to actually render the scene. This is more 
> so true on multi-core machines.
> 
> The AO ability is certainly possible. SNOW-9 was a stub for gesture 
> recognition, but it could easily use this API instead. There is 
> different ways to achieve this, and I thought simplest way would be to 
> like wear animation/gestures much like one wears clothes, or maybe 
> something like the interface for attachments.
> 
> Probably more of interest than an AO right now is to have LSL-editors 
> use the API. When you open a script in-world, it would actually open 
> your client-side script/program of choice to edit. There are some good 
> ones out there.
> 
> I've said too much... (not really *wink*)
> 
> Lillian Yiyuan wrote:
> > More on topic for the viewer. Many of that activities currently
> > performed by scripts should be done primarily out of viewer resources,
> > these include, but are not limited to, AOs, radar, scripts on
> > attachments, flight enhancement and so on. One short road to making it
> > so that script limits are not noticed, is to take off the server the
> > long list of activities that are server side, but do not need to be
> > there. If most avs can wear their clothes and their AOs and a few
> > gadgets, they will not notice scripting limits, and there will be more
> > resources for physics, graphics and so on. Client side scripting is
> > not easy but there have been enough implementations of it in various
> > places to show that it is practical and not fatal to sim performance.
> >
> > Many of these enhancements have already been put in to open source
> > clients, and therefore are good targets for implementation.
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting privileges
> >
> >   
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

-- 
Carlo Wood <carlo at alinoe.com>