On Mon Dec 1 18:45:43 2008, Dirk Meyer wrote:
I like the idea, but what happens if I switch clients during a
conversation? In your example, we chat with the desktop client. I
think
we are done, but do not close the chat window (I sometimes do that).
(I always do... I leave chat windows open as a to-do, or just because
I'm always too lazy to do tab cleanup).
Now
I go away with my mobile client. If you send a message now, I guess
the
message will be send to the full JID of my desktop client and I
will not
get the message. Maybe a thread can expire somehow and after a
time, we
should send to the bare JID again doing the whole 'mine' thing
again.
But timeouts are something we're intending to avoid here.
Or am I missing something here? I'm do not know the way how chatting
works with full and bare JIDs.
No, what generally happens is that the "opener" in a conversation
goes to the bare jid, and when the recipient replies, the sender
"locks on" to the full jid.
I'm wondering if we can split the issue, here, and instead have two
mini-protocols:
1) The "Hey, I have pending messages here!" one. (ie, a bare_jid-wide
version of the flashing taskbar item thingy.)
2) The "Give me your pending messages!" one.
I'm wondering if intra-jid presence can be made to do the first - so
the clients would send a directed presence to their own bare jid
which contained "private" status, including any pending messages.
The (2) can be done as a standardized ad-hoc command, probably. In
fact, I think we have one in the "forward unread messages" one.
Assuming the intra-jid presence trick can be used, then servers need
to do nothing. Otherwise, I'm tempted to suggest that we simply
standardize that hack, and then we've a general method for doing
similar things.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
