[standards-jig] NEW: Chat State Notifications (JEP-0085)

Tijl Houtbeckers 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.
>
>http://www.jabber.org/jeps/jep-0085.html
>
>Peter

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

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? 


-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list