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 [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]/foo).
> - If [EMAIL PROTECTED]/foo goes offline, then I unlock the window and start 
>   sending messages to [EMAIL PROTECTED] 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
>   [EMAIL PROTECTED]

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 [EMAIL PROTECTED] 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               [EMAIL PROTECTED]
Imendio HB                     http://www.imendio.com
Phone: +46 (0)709 718 918


_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Reply via email to