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

Cedric Vivier cedricv at neonux.com
Tue Jan 4 17:40:28 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Trejkaz Xaoza wrote:
| Part of the advantage of composing events
| (and the reason IM clients started using them in the first place) is the
| bandwidth savings over relaying every character.
It's up to the client to decide how frequently to send tokens (every
character is of course something to be avoided).

| Only the last word?  What if the user typed more than one word in that
time?
| (e.g. fast typer, or pasting from the clipboard)

Well I may should have written it as:
Clients SHOULD send the last tokens (delimited by spaces) typed within a
short delay (500ms for instance).
Of course, the client sends nothing if the user doesn't have entered
anything new and SHOULD NOT send a composing body event if a word is not
terminated, ie. no end delimiting space).

| What if clients disagree on what is considered to be a token?  I think it
| might be safer to use a character count for this, and enforce the count
| attribute in all cases where something is being replaced.
@count is actually the sequence of token(s). Not the word count.
Example:
token 1 :  <body>I love</body>
token 2 :  <body> you!</body>

| What if the client deletes the first word from the sentence?  Do you
clear the
| whole thing and append the tail?
In the current proposal yes :/  (for easy implementation)


| To rethink this, clearing and appending are both kinds of replacing:
|  * To clear some characters, you replace them with nothing.
|  * To append some characters, you replace the zero characters at the
| end of the body with those characters.
|  <!-- Replace 'I' with 'you'. -->
| <body start='0' end='1'>you</body>
Yeah it can be cool but it's more complex to implement and wastes even
more bandwith :o)

| which is a little more consistent, but in the end it's still expensive in
| terms of bytes. :-)

It's up to the client to decide when to send composing body updates. For
instance a client won't send composing body if it's less than X bytes or
the token is not space-terminated or more than 1 time per second.
This shouldn't be used as a character-by-character composing mode ;)


- --cedricv
jid: cedricv at jabber.neonux.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQdrVDC7DGrBzh2VQAQLOqwgAjAKrYywzfopEbro3o4UYpa4ibJKHa8WK
ElG5i0ueUadHe7e/NVNvsGTZ9aGyzjEnXMkmHCuQV1cFP5WAXR9z7Vmbyt/LLXPx
Mn0a1ZvcRqP9bhUpA53X0nMZON1FyQPXGHsE6klNQy5DZ8xonGc22kZMdPv8D6t4
1vtslIhopi3dd8h6czARtdhO7VWW3HISSeSX5q4ZUYtzP5uYVP1vN4/qmkzYxE3z
pnXADDOQJwCmGM+DwJWKEuRF/eLXiL97rEMfCYdLkBvntDXGGR9dy0vQoSVxknbQ
/zwiErqTGM5GmTXtRT7lseXjQ8QDiqe9N/AOCwAVQV5BupI2jzLtkQ==
=AnsK
-----END PGP SIGNATURE-----




More information about the Standards mailing list