[sldev] Generic LSL->Client Comms
secret.argent at gmail.com
Wed Feb 28 06:56:49 PST 2007
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:
Say "throttle up" on channel 32. All chat messages must be preceded
<send_message channel="32" type="chat">throttle up</send_message>
Say "throttle up" on channel 32. All single-line XML messages must
begin with "<".
<send_message channel="32" type="chat">
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
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
> 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
> 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.
More information about the SLDev