[standards-jig] NEW: Chat State Notifications (JEP-0085)
thoutbeckers at splendo.com
Tue May 20 07:26:36 UTC 2003
Peter Saint-Andre <stpeter at jabber.org> wrote on 20-5-2003 2:01:20:
>I've published a new JEP for chat state notifications. Please note well
>that this JEP does *not* address message tracking, only notifications
>regarding chat states such as composing a reply. We will need another
>JEP to address message tracking.
I think this JEP will make the use of <thread> even messier. There's
already a known problem when clients that do not support multiple
threads at the same time try to talk with clients that do. This is for
me reason enough not to support <thread>, since this is also the only
way to signal to other clients that I do not support multiple
Currently I would not loose much functionality with this, but with this
JEP that would mean I can not have chat state notifications. So I'd
have to implement the same hack many other clients do, "just copy back
the last threadid you got". As if that's not bad enough, the only way
I'd be able to track mulitple induvidual messages is starting a new
thread for each one and always use type="chat". And once I do have my
<thread> system in place suddenly every thread I make can be closed and
invalidated by the other client. I can see the benifits of using thread
based tracking (eg you can do the focused/unfocused thing more easily)
but realise that using <thread> brings along it's own disadvantages.
Some other questions.
Why am I not allowed to disco for Chat State Notifications first, and
send an initial message that the thread is composing/focused/etc?
Under example 1 the JEP states:
> 1. MUST send the initial message to the Contact's bare JID (user at host)
What is the purpose of this? If I want to send a message to specific
resource why should I be forced to send the initial message to the
(potentially) wrong resource?
Software Engineer @ Splendo
More information about the Standards