[Standards] Message Mine'ing

Dave Cridland 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  
> 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  
> 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='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:  
	<messages xmlns='urn:xmpp:tmp:messages'>
		<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  
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list