[sldev] Generic LSL->Client Comms

Argent Stonecutter secret.argent at gmail.com
Tue Feb 27 14:51:23 PST 2007


On Feb 27, 2007, at 3:26 PM, Dale Glass wrote:
> В сообщении от 27 февраля 2007 16:21 Argent  
> Stonecutter написал(a):
>> Dale: ever thought about taking your code and combining it with side-
>> chat on a well known port to let people start writing scripts that
>> talk to LSL directly, now, without waiting for an internal plugin
>> architecture?

> I'm not entirely sure what's the point of that though. Why use the  
> viewer to
> pass chat messages through when you could use libsecondlife instead?

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.

> If I was doing the client listening on a socket thing I'd use a  
> much more
> complete protocol for program/viewer communication. Probably  
> formatted in XML
> (since the viewer already uses a parser might as well use that) and  
> with the
> ability to talk to the viewer itself. Then this would be a minor  
> part of the
> available functionality.

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

> If you just use the viewer to pass chat messages back and forth  
> then it's hard
> to write anything very interesting, and any GUI would be  
> problematic, as
> you'd lose it if using SL fullscreen for example.

The majority of the cases I'm thinking of need no GUI at all, or the  
whole point is to add a GUI to something on the computer inside SL,  
in a HUD attachment for example. Doing it through the existing  
communication channels is cumbersome and requires running a  
mailserver or a webserver that's not NATted to initiate the  
connection even with XMLRPC.

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.

Local scripts communicating with HUDs, to provide in-world UI for  
local applications.



More information about the SLDev mailing list