[sldev] Generic LSL->Client Comms

[Argent Stonecutter]

On Feb 27, 2007, at 5:54 PM, Dale Glass wrote:
> Why "anyway"? If all you have is a chat channel, and none of the  
> client's
> benefits, then about the only benefit over using libsecondlife is  
> that you
> get the viewer to speak for you.

Which is a pretty damn important one. It's kind of essential for HUD  
and vehicle control.

> What I mean here is: You lose a LOT of things if all you do is to pass
> messages back and forth. So why limit it to that?

Because I'm looking at making this easy to use for the kind of people  
I find myself helping with LSL scripting on a regular basis.

> Make the viewer accept
> complex commands, or at least make it so that they can be added  
> later without
> breaking the protocol.

Fair enough. But the format for the simple case needs to be simpler  
than XML.

> First, if the code is outside the client and all you have is  
> message relay it
> means you must shift focus to app doing the control stuff.

Not at all. The app doing the control stuff wouldn't ever have focus.  
There's no reason it should, in the usual case it's not taking input  
from the keyboard-mouse stream, it's taking it from a third device  
that's not even in the normal GUI stream, like foot pedals for  
acceleration and braking.

> Also, without changing the viewer you don't have the ability to  
> make the
> vehicle move on screen before the command gets to the server. That  
> results in
> annoying lag.

Um, the vehicle movements in SL are controlled by the linear and  
rotational motors, the user's control inputs aren't meaningful to the  
client at all... they're passed to the script which changes the motor  
parameters. There's nothing to base client-side prediction on... for  
aircraft, at least, the only controls that are near universal are  
left and right and how they behave differs from one craft to another.

And things that I'm interested in are things like throttle, weapons  
and payload, and flight mode, and they're way outside anything client  
prediction would be useful for.

> This is also very not ideal. For example, my avatar list would lose  
> the
> ability to get the avatar list from the viewer itself, and would  
> have to run
> a sensor in the LSL script, which is must limited in its capability.

What does your avatar list have to do with this? I'm talking about  
things like music player controls, local environment sensors,  
scriptable applications you're running anyway that you want to keep  
an eye on while you're full-screen *and* in world. Moving towards "SL  
as desktop".

> And so on. Doesn't have to be specifically XML of course, but I do  
> think it
> shouldn't be as simple as plain text with no metadata at all as  
> that limits
> the possible functionality.

The structured format shouldn't be as simple as plain XML either,  
because socket communication is streamed... if the viewer or  
application lags you can get multiple messages concatenated in a  
single "read"... and as your example shows a complex protocol needs  
to be able to embed newlines.

What I generally do is something like this:

If the message starts with a pound sign, it's followed by a byte  
count and a formatted message.

Otherwise the message is a single-line unformatted message.

I've used this scheme in several applications over the years. The  
unformatted message makes debugging easy, and the counted formatted  
message avoids quoting hell.