[sldev] Generic LSL->Client Comms

Dale Glass dale at daleglass.net
Wed Feb 28 16:38:36 PST 2007


В сообщении от 28 февраля 2007 15:56 Argent Stonecutter написал(a):
> 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.
I don't really get why everybody keeps bringing up context switches and 
network stack overhead, when both are constant, not all that big, and getting 
progressively smaller as CPU speeds increase. 

I think that a much better argument could be made that there's going to be a 
significant impact from converting internal data into some format like XML, 
then parsing it again on the same box, when all that data could be accessed 
for free if the plugin was loaded into the client.

Now, I still think this way of doing things is interesting. It sure is 
inefficient for things that would involve sending megabytes of data back and 
forth, but some light communication like "process this key", "start 
streaming", etc would be really useful.

> 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.
I don't know why, XML isn't all that complicated. Granted, it's not the 
prettiest thing, but it's not anything all that weird either. Anybody working 
on something like this can be assumed to have seen at least some HTML, and if 
you get that, you're 90% there regarding XML.

After all, you can make a simple XML protocol. There's no need to use every 
esoteric piece of functionality in it.

> 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 "@"
Well, here you have what I'm talking about. This is nice and simple on the 
surface. Now:

What is the "," for?  There you have a weird bit of syntax already.

Will the parser handle a negative channel?

How do you indicate shout or whisper?

Will the parser correctly deal with unicode? Specifically, will it correctly 
detect characters it's looking for, while avoiding the pitfall of that a 
character can be both itself and a part of a multibyte UTF8 character?

What if you want to send multiple lines?


I have a quite strong dislike for homebrew protocols for this reason. Are you 
sure that a couple months later you won't have to keep adding weird hacks to 
keep this compatible? 

Such a thing would need to be properly made to deal with eventual expansions.  
I think PNG has a good idea in this regard: You can add new sections to it, 
and the section's header specifies whether handling it is necessary or not in 
other to display the right result. 


>
> 	<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.
And now you have the problem of having to implement the same thing twice. That 
almost guarantees that one version will have a bug and another won't, or the 
functionality will slightly differ. That's bad.


> 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.

Ahh. Ok, that makes sense.

-------------- 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/20070301/1f81d83b/attachment.pgp


More information about the SLDev mailing list