[Standards-JIG] Disabling chat states and what the JEP should say

Nikos Kouremenos kourem at gmail.com
Fri Aug 5 09:54:27 UTC 2005


Hello everyone,

recently our client (gajim.org) implemented Chat States. Last time
I've read the JEP (yes it has changed but I don't think something was
added in that area), it did mention about disabling chat states, but
it didn't make any difference between both peers do not do chat state,
or one of them doesn't want to do anymore. The latter means: I don't
want the other party to know if I'm composing, closed the window etc..
but I want to get such info by him/her.

In our implementation if a contact is marked as being able to recevie
chatstate we send until Gajim is restarted (and then we ask again). So
let's say I marked plato that he can do chat states, plato goes to
disable chat states. What will happen is: he will stop sending me
chatstates, but I (who have him marked as being able to receive) will
keep on sending until I query him with active which is not gonna
happen unless I restart my client.

Now I may missed sth in the JEP but still I couldn't find any xml for
plato to send and tell me: "hey stop thinking I wanna receive your
chatstates" or "start the query procedure again (send me <active/> and
wait for me to reply to that, or else at last get to know I don't want
your chatstates"

This is in the spirit that 'disable chatstates' in the JEP is not
explained enough, and something must be mentioned about sending and
receiving chatstates as 2 seperate things.

ps.
Yes client of plato can check if he has them disabled, and just do not
show in the GUI, but xml of chatstates will be always received. So if
this is the answer to my question, maybe a place where what exactly
means disable chatstates for clients is necessary in the jep imo.
(afterall that JEP likes client devs in other places so much, why not
there too)

Sorry for big mail for just a small problem
-- 
Nikos Kouremenos | Jabber ID: nkour at jabber.org | http://members.hellug.gr/nkour



More information about the Standards mailing list