[JDEV] Chatting with the correct resource

[Mikael Hallendal]

ons 2003-11-05 klockan 21.05 skrev Peter Millard:

> This stuff has come from experience of the jabber community (client writers
> mostly). Not from a "marketing droid" survey of some kind.

So it's mostly come from hard core jabber folks :) We are targeting
people that know nothing (and don't want to learn) about the Jabber
protocol.

The resource and priority settings are therefor typical things that we
do not want to bother the user with.

> "Following the client" is a LOT harder than this one scenario. The model 
> that I use in Exodus is this:
> - When a user dbl-clicks a contact in the roster, open a chat window and 
>   send the first message to user at host. This allows the server (and
>   possibly filtering rules setup by the recipient) to determine which
>   resource to send the message to.
> - When I receive a reply back, I "lock in" that resource (user at host/foo).
> - If user at host/foo goes offline, then I unlock the window and start 
>   sending messages to user at host again.
> - If the user sends me a reply from a different resource, I lock in that
>   new resource.

This sounds all good, except that I want to be able to also unlock the
window if the user connects again with a client with higher availability
(ie. higher priority).

> [.. and here is the kicker ..]
> - If I _close_ my window, and dbl-click the same contact, I reopen the 
>   same window (showing old messages), but reset the jid back to
>   user at host.

Would be very nice to be able to do this without closing the window. And
it's possible by just resetting it when you receive a presence with a
higher priority then the one you are currently locked to. However, from
what I understand this doesn't comform with the spec.

> What typically happens in the situation you describe above is that 
> when you go away, I would _usually_ (but not always) close the window.
> Which resets the JID back to user at host. This is how the majority my
> users seem to operate (based on feature requests/bug reports/private
> email, etc..).

This sounds like a work-around that the user has to handle himself
everytime. This is really hard to solve in a nice way, other IM systems
don't have the problem since they don't allow multiple logins. 

Regards,
  Mikael Hallendal
-- 
Mikael Hallendal               micke at imendio.com
Imendio HB                     http://www.imendio.com
Phone: +46 (0)709 718 918