[Standards-JIG] Re: Live Chat extension to Chat States (JEP-0085)

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Jan 21 20:04:14 UTC 2005

On Fri, 21 Jan 2005 20:36:56 +0100, Cedric Vivier <cedricv at neonux.com>  

> Tijl Houtbeckers wrote:
>> As for a justification, it's faster than waiting for a message, that's   
>> reasonable enough. What more justification do you need? With that kind  
>> of  additute we'd still be running this discussion list with postal  
>> pigeons ;)
> I agree, and don't forget the "fun"/wow factor ;-)   [IM for (pre)teens  
> for instance]
> Also character-by-character may be overkill, word-by-word should be  
> sufficient in most cases (the proposed protocol let the client  
> implementation choose how much info to send... yeah I know in-band was  
> stupid and I have to work on another proposition out-of-band this time).

Well, I don't think it's impossible to do it inband. It shouldn't be. The  
idea behind Jabber used to be, keep it simple for the client, XML based,  
client-server. If you suddenly get disconnected from servers because of  
"karma" or whatever it'll be called, that's a problem Jabber has with flow  
control. Solution should be better flow control. If it costs too much data  
traffic because the XML is too bloated, then this is a problem with the  
way Jabber uses XML. Solution should be reducing that.. in your case the  
stanzas send are nearly identical so there's a potential for insane  
compression rates there.

Of course, if these things do turn out to be a problem for you, it might  
be the easiest for you to go out of band if you want to get quick results.  
(And thus loose most of the advantages behind these ideas of simple,  
server based processing).
I'm not entirly convinced it will be a big problem though. If you keep  
your update rate at a reasonable level, and just use a normal message  
stanza with your own namespace and the replace / insert positions there's  
no reaons servers shouldn't be able to cope with it. I'd do some actual  
testing before before listening to the.. let's call them more sceptical  

More information about the Standards mailing list