[Standards-JIG] PROPOSAL for Live Chat

Heiner Wolf wolf at bluehands.de
Sun Jan 7 15:18:12 UTC 2007


in LLuna we are using Live Chat for years. We are working with the 
APPEND + REPLACE model. In usual typing APPENDS are sent. Not for every 
key stroke, but frequently. If the user changes something in the middle, 
then the client sends a REPLACE.

We started with only the REPLACE mode. My argument was, that a typical 
IP packet with XMPP stanza is between 100 and 150 bytes (we have long 
chat room names). If users type between 20 and 100 characters, then 
there is not very much to safe with a sophisticated DIFF protocol which 
addresses character positions and such. On the other hand, especially in 
a public chat room, if someone comes late, then it is nice to get the 
full text, hence our initial REPLACE model.

We send a message quickly after the key stroke, then no message for at 
least 200ms. If the line length grows, we delay depending on the payload 
length up to 3 seconds.

For backward copatibility we send the REPLACE and APPEND messages as 
extension and send a plain message after the user hits ENTER.

But after some time we noticed, that it may be simple, but it just sucks 
to watch the traffic log. If a user types, you see a triangle growing 
from 100 bytes to 200 bytes. I know that all the REPLACE payloads make 
only 1/4 of the traffic compared to a pure APPEND, but the protocol 
developer in me just could not stand all the wasted bytes. So we added 
APPEND to our pure REPLACE, if there were just a few characters 
appended. After all, from the techical view I think it is "wrong" to 
send all text always. Added text looks "better", seems more "correct" 

I think the ICQ style with every key stroke for hours is not backward 
compatible to the way chat rooms work. It mightbe nice for 1-to-1 chat.

My summary for a backward compatible live chat:
- if the string just becomes longer, then APPEND.
- if something changes in the middle, then REPLACE
- if user hits ENTER, then plain old message.
- send fist change quick, then delay minimum 200 ms depending on the 
payload size.

Dr. Heiner Wolf
+49 (0721) 2542 369
Open Source Future History: www.galactic-developments.de

More information about the Standards mailing list