[JDEV] Re: Chatting with the correct resource
tony.cheung at asiayeah.com
Thu Nov 6 18:58:26 CST 2003
Hi Mikael and others,
This thread is certainly interesting and is exactly the same problem I
have right now while developing a Palm Jabber client,
While I am still trying to digest every thoughts in this thread, I just
want to share my own experience first.
Mikael Hallendal wrote:
> ons 2003-11-05 klockan 19.14 skrev Joe Hildebrand:
>>This is one of those things that is a little counter-intuitive. The
>>language that's in the spec is correct, particularly when combined with
>>the rule that if a message is sent to a non-existent resource, it gets
>>delivered as if it has no resource.
>>There have been clients in the past that always sent to the user at host jid
>>(which is what you are suggesting), and user-experience-wise, they aren't
>>great, since some of the messages in a conversation end up going to the
>>two different resources, as auto-away priority changes happen.
> Any pointers to these clients and a discussion on what wasn't great
> about them?
Chatopus (current beta stage) always send messages to user at host without
considering the particular resource. It also always send messages using
the type chat, without using any thread ID.
My original assumption is Jabber wants most intelligence in the server
side. As a client, especially a mobile PDA client, I suppose it does not
need to dealing with the resources. However, it does not seem to be the
To simply things further, the roster list of Chatpus also only display a
single presence indicator for each user, no matter if a user has logged
on with multiple resources. Basically the highest online status will be
shown. For example, if a user is online with resource A and away with
resource B, the online indicator for that user is online.
So far, everything seems easy to deal with and understand.
Now, the problem comes. A user logs in with resource A and then resource
B. Chatopus receives a message from resource B. When it tries to reply,
it sends the message to user at host. Now, the message may be routed to the
client on resource A, while the user with resource B is waiting
deperately for the reply...
As a mobile client, Chatopus cannot afford to have multiple windows open
at the same time. So basically it maintains a message history for each
user, user at host. When a user clicks on a jid, the message history window
is always opened and a previous message is always there. One way is to
always send messages to jid at host/resource of the previous message, but
then it does not take into account of the priority of different resources.
I don't easy an easy answer and perfect implementation yet...
What about the following?
One suggestion is to have some feedback from users acknowledging the
recipient of messages.
In this scheme, the client always send messages to jid at host. When a
particular resource (highest priority) receive the message, an
acknowledgement should be sent back to the server, only if the real
human user is really there, read the message and confirm by clicking
something. If the user acknowledgement isn't received within a certan
duration, the server detects the user may not really at resource B and
would then try to route the message to resource A as a backup. This does
not involve the sender side, but the receiver side needs to provide a
feedback confirmation. Also, most intelligence is now on the server side.
Anyone agreeing this little scheme? Is it something available now?
P.S. BTW, please feel free to try my Chatopus client, as it is near the
1.0 phase. I would appreciate if more experienced Jabber
users/developers try it.
>>The rules that are in the spec are our based on our best practices based
>>on real use patterns that we've seen.
> Hmm .. so someone (Jabber Inc.?) has made real user testing regarding
> this and come up with the fact that trying to send to the client where
> the user is is a bad idea?
> And then the spec. enforces the client author to conform with these
> findings? I think it's a bit weird that the spec. should enforce how the
> UI that implements it should behave.
> Any suggestions on how to handle this then? For example, I change
> computers and goes to my laptop, my desktop client is set to away (by
> autoaway or manually setting it to away), I log into my laptop. My
> friend who I where chatting with before writes me an important question,
> which goes to my desktop since he happened to chat with that resource. A
> few hours later I go back to my desktop and see that he has written the
> If the message followed the client where I actually is, this wouldn't
> have happened. Is there any solution to this with the current spec?
> Mikael Hallendal
More information about the JDev