On Tue Dec 2 19:10:12 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
> 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.)
>
> 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.
>
> 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.
Presence, message, what difference does it make? I see no special
reason
to use presence instead of message here, in fact it doesn't have
anything to do with presence so I'd prefer message.
Well, I picked presence for two reasons. Firstly, it does have to do
with the client status, which is arguably presence rather than a
message. Secondly, it has the routing properties we want without
having to change the server at all, which is, to say the least,
rather convenient.
Then the question is: does your proposal (which I don't grok,
perhaps
you could post more details) cut out the server in a way that the
MINE
stuff doesn't? Are you perhaps suggesting a generalized algorithm
for
construction of a UUID for each message, so that the claiming
client can
send a special message (or presence) to the other resources so that
the
others know it has claimed the message?
No, not at all. I'd assumed that only a single session would get the
message, rather than all of them. This means that instead of having a
message, and then having to "claim" it, the client would look for
other clients which had unseen messages and get them resent to it if
the user appeared to be looking for them.
I think I'm missing something here. Yes it would be nice if we
didn't
need to change any servers to make this happen (just make it so that
they send bare-JID message to all resources),
No, that's the bit I'm proposing need not be changed.
but it's not clear to me
how we can make that work.
So... My desktop gets a message:
<message from='[EMAIL PROTECTED]/thing'
to='[EMAIL PROTECTED]/desktop-client'>
<body>You still there?</body>
</message>
But, sadly, I'm not there - I've walked into the ktchen to boil the
kettle. Luckily, I do have my mobile device upon me. My desktop
client doesn't know I'm not there, it only knows I've not yet waved
my mouse upon the window, so it's doing the orange-flashy-thing in my
taskbar. (These things probably have good, proper, names.)
But, as well as that, it also does this:
<presence to='[EMAIL PROTECTED]'>
<!-- Usual current presence, as broadcast, but also private stuff:
-->
<messages xmlns='urn:xmpp:tmp:messages'>
<message from='[EMAIL PROTECTED]/thing' count='1'/>
</messages>
</presence>
Now, my other clients all see this, and can Ding accordingly, flash
their taskbar bits, or whatever else it is that they do. (They might
do this only after a short period, of course, but then, my desktop
client might only send out intra-jid presence updates after a short
period, too).
As it happens, I hear the ding whilst the kettle boils, and look at
my mobile device - sure enough, there's a notification with stpeter's
name in it. Since, yea, even unto the tea break, I wait upon every
word that he doth utter, I open up the message eagerly.
And the mobile device *then* can ask my desktop client for the
message (via XEP-0146, or something that perhaps only gets messages
from a single jid), and show it to me.
I reckon the user experience is spot on, there, covers all the
use-cases, and really, the only disadvantage I see is that I was
actually quite keen on a big button marked "Release Mines".
OTOH, it does keep priority based routing, and allows it to remain a
feature instead of a plague - but one that users can gleefully
ignore. To be fair, though, it doesn't work well with servers that
broadcast messages to equal priorities - I'm not sure it hurts that
much, though.
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
