[Standards] Message Mine'ing

Peter Saint-Andre stpeter at stpeter.im
Wed Dec 3 04:11:53 UTC 2008

Thanks for the explanation. Grokkage in progress. Questions shall follow.

> 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>
> </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='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'/>
> 	</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: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