[sldev] Generic LSL->Client Comms

[Dale Glass]

В сообщении от 27 февраля 2007 23:51 Argent Stonecutter написал(a):
> Because connecting to a socket is a few lines of code, because you
> can connect to a socket in just about any scripting language on any
> platform, because you're using the viewer anyway, because libsl
> doesn't connect through the viewer.

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.

You could do the socket thing in libsecondlife as well, or even easier, a 
pipe.

> This isn't about program-viewer communication, this is about script-
> script communication.

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? Make the viewer accept 
complex commands, or at least make it so that they can be added later without 
breaking the protocol.

Make it so that you can request the viewer to control the music, accept 
external keypresses, upload files, etc. And one of the available commands 
would be setting up this message stuff.

In fact, that was one of the things in my TODO list: Make a socket protocol 
that would allow me to tell the viewer to accept scripts, compile them, and 
automatically send to the right place in my inventory.

> A couple of obvious applications:
>
> Controls sending chat messages to vehicles. This wouldn't even need
> return messages, and could be used with existing vehicles.
This is far less than ideal.

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. I suppose you 
could capture the input while SL is active, but then it'd conflict.

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.

I think a better approach would be to have an app tell the viewer "Act as if 
this key was pressed". Then you get the benefits of client-side prediction.

> Local scripts communicating with HUDs, to provide in-world UI for
> local applications.
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.

It would also lose the ability to open IM and profile windows, making the 
avatar speak and setting beacons.


Now, if you want to use my hack to talk to in-world objects that way, sure, go 
ahead. But like I said, I'd use a more complex protocol for the 
communication. The hack was done to be as simple as possible for the LSL 
side, but it's not all that great if you have more powerful things available.

Here's how I'd do it:

Client to viewer on socket:
<send_message channel="324" type="whisper">Hi there!</send_message>

LSL script replies:
$VwrComm$0$Foo$Widget online

Viewer outputs this on the socket:
<message type="object" key="123123" owner_key="1431231" subsystem="Foo">
Widget online
</message>

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.


>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070228/a6f9f11d/attachment-0001.pgp