[Standards] Message Mine'ing
dave at cridland.net
Tue Dec 2 23:43:45 UTC 2008
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
> > mini-protocols:
> > 1) The "Hey, I have pending messages here!" one. (ie, a
> > 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
> > that hack, and then we've a general method for doing similar
> Presence, message, what difference does it make? I see no special
> 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,
> Then the question is: does your proposal (which I don't grok,
> you could post more details) cut out the server in a way that the
> stuff doesn't? Are you perhaps suggesting a generalized algorithm
> 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
> 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
> 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='that-stpeter-chap at jabber.org/thing'
to='dwd at dave.cridland.net/desktop-client'>
<body>You still there?</body>
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='dwd at dave.cridland.net'>
<!-- Usual current presence, as broadcast, but also private stuff:
<message from='that-stpeter-chap at jabber.org/thing' count='1'/>
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
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
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards