[Standards] SIFT revisited
stpeter at stpeter.im
Mon Jun 8 22:22:34 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 6/5/09 5:29 PM, Dave Cridland wrote:
> On Fri Jun 5 23:57:06 2009, Peter Saint-Andre wrote:
>> Fabio Forno has found some good results with SIFT on a mobile phone:
> Hmmm - I had a long chat with Forno the other evening, and I've been
> meaning to write it up in a more formal way for us all to share...
> The general idea is that instead of SIFT at all, we have a single
> command which simply says "Don't send my presence *until* you've
> something else to send me."
"Don't send my [outbound] presence" or "Don't send me [inbound]
presence" or both? Based on previous discussions, I assume the latter.
> - or turns off that state. Nothing gets
> dropped, just delayed, maybe by a maximum time.
IMHO, how the server gives you the most up-to-date presence information
is an implementation matter. It could queue up inbound presence
notifications or it could send a new probe when you ask for presence
again or it could do some combination of the two (queue until the cache
becomes too big, then flush the cache and probe if needed).
> So <presence/> gets buffered until either a <message/>, or an <iq/>,
> needs sending.
Needs sending inbound to the client? I assume so, just making sure.
> The client can flush the pending presence in a number of
> ways, the most obvious one being simple using a XEP-0199 ping - the
> response being quite sufficient to flush the presence down.
What exactly do you mean by "flush the presence down"? Do you mean that
the server sends updated inbound presence to the client, or that it
empties the server-side cache?
> The user experience looks roughly as if presence is sometimes out of
> date for a short while, but if a message arrives, it would "push down"
> any delayed presence updates, so it wouldn't be often.
Yes, I think that is the desired outcome w.r.t. to presence.
> This is, I'd note, a pretty simple protocol to implement, and the
> interesting thing about Fabio's experiment is that it shows it'd give
But AFAICT it doesn't address all the use cases we discussed at XMPP
Summit 6. I might want my mobile device to be awakened only if I am to
receive a phone call (Jingle invite) or a "useful" message (for some
value of "useful" -- e.g., perhaps not some random, low-priority news
> If we want to get complicated, we can point out that if we're buffering
> presence anyway, we might collapse presence stanzas that are overtaken
> by events - so if you go away, then xa, then offline, the server *might*
> drop the away/xa changes, and just give the phone a single offline.
I definitely think that is the desired behavior. I don't care what your
presence *was* five minutes ago, I care what it is now.
> Now, the reason I don't think the rest of SIFT helps is that I'm not
> convinced that much "unsolicited" <iq/> traffic actually happens,
How about unsoliticited <message/> traffic? I'm not talking only about
PEP stuff here, but news feeds, chatroom invitations, roster item
exchange messages, etc. I grant that it's difficult to sort through all
those, but that's what something like SIFT would give you. However,
perhaps we get the biggest bang for the buck with presence only.
> because well-behaved actors, at least, will check the disco#info and
> only send <iq/> stanzas supported by the remote end.
As to IQs, we'd need to look at our full protocol suite to see what's in
play here (we can at least add file transfer to your list), but you
might be right that "well-behaved" actors won't send too many extraneous
> There are
> exceptions, such as version queries,
> vcards from MUC (please, folks, fix
What *exactly* needs fixing here? Separate thread, please. :)
> and pings - the latter, of course, rather relies on getting
> Actually *dropping* data just strikes me as poor - I think we can do
> much better than that.
For messages, I think the spec would recommend throwing them into
> FWIW, I *do* think that people want to have the concept of a "session
> roster" vs "full roster", but I think that's a different problem to
> solve. (And one that's quite easy, too, but harder to implement).
OK, thanks for the feedback!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards