[sldev] Generic LSL->Client Comms

[Argent Stonecutter]

On Feb 27, 2007, at 9:22 PM, Dale Glass wrote:
> I also thought you wanted to implement plugins in this way, by  
> doing it all
> through a socket.

Not really. For a lot of plugins the extra trip through the kernel  
and network stack is a lot of overhead, particularly for  
transformation plugins and things like Jesse's prim attributes, or  
for your floater for that matter if it's polling for avatar data.

What I'm looking at here is communication between applications on the  
client's computer and applications running in LSL. This is a subset  
where the latency and overhead of a socket is lost in the noise, and  
where there's already a lot of people in SL who are doing similar  
things between objects using chat. I think a lot of these people  
would be able to effectively use a simple system like I'm talking  
about, but would be overwhelmed by XML.

Having a socket that applications can connect to that maps into chat  
doesn't preclude having a more complex and powerful protocol running  
over the same connection or over a related link. Consider this:

	@32,throttle up

Say "throttle up" on channel 32. All chat messages must be preceded  
by "@"

	<send_message channel="32" type="chat">throttle up</send_message>

Say "throttle up" on channel 32. All single-line XML messages must  
begin with "<".

	#66
	<send_message channel="32" type="chat">
	throttle up
	</send_message>

Say "throttle up" on channel 32. All multi-line XML messages are  
preceded by "#" followed by the number of bytes in the message and a  
newline.

Other meta-control messages could include "register-id" for the  
$VwrComm$ response, or something to request a feed of all chat, all  
llOwnerSay messages, all llInstantMessage messages, all user-user  
IMs, and so on.

> Anyway, you still can do prediction for the avatar, so I still  
> think sending
> keypresses would be the better way. Will work better if you want to  
> control
> the avatar, and doesn't need a script to support it.

Maybe. I'd like to have more control than that over cyberflight, though.

>> things like music player controls, local environment sensors,

> LSL is rather weak for this. If you want stats, just get them from  
> the client
> itself, which gets a whole lot more, and you don't even need to  
> request
> anything extra.

Heh, you read that exactly the opposite way that I meant it. Sorry,  
let me clarify: I'm talking about controls in your HUD to make iTunes  
do stuff, or to tell you what your local outside temperature is, or  
how much mail you have, so that you can get the kind of info you put  
in your desktop / dashboard / icon-tray / panel / insert-your- 
preferred-desktop-plugin-here when you have SL in full screen mode.