[sldev] Client-side scripting is real

Dzonatas Sol dzonatas at gmail.com
Wed Dec 23 14:40:42 PST 2009


Yes, XML is being used in SNOW-375.

The viewer sets up LLIOHTTPServer to listen on a port (default: 50140).

A peer then connects to the viewer with the resource URI: 
http://x.y.z.w:50140/Interface/Connect

Content-Type is set to: llsd+xml

An XML packet then contains the request data in which the viewer uses to 
connect back to the peer through a TCP socket that stays open.

Unsolicited events from the viewer to the peer are sent via the TCP 
socket, for now. These could via a HTTP listener on the peer end instead 
of a TCP socket, but I wanted to avoid firewall issues for now. This can 
be later programmed optional as specified by the XML data in the 
/Interface/Connect method. Each request sent over the TCP socket is 
LLSD+XML based with null as the delimiter. These messages should not be 
bigger than a UDP packet. This TCP connection can be treated just like a 
UDP connectionless endpoint with packet loss and/or limited buffers.

A successful /Interface/Connect than establishes a cookie for the 
session to use in other URI resource requests.

Other requests, like for avatar information, gesture data, group info, 
etc, are all done by URI resource nodes on the LLIOHTTPServer. All 
messages that can be larger than a UDP packet have to have a node. 
Anything that requires stateful tranfers must use a node (hence, no 
specialized reliable UDP support needed here).

LLSD+XML is used to keep the API to a lite-weight footprint in the viewer.


Carlo Wood wrote:
> 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
>>     
>
>   



More information about the SLDev mailing list