[JDEV] Re: Chatting with the correct resource

[Tony Cheung]

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, 
http://www.chatopus.com

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 
case.

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?

Tony Cheung

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
> question.
> 
> 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?
> 
> Regards,
>   Mikael Hallendal