[Standards] SIFT revisited
dave at cridland.net
Tue Jun 9 09:11:04 UTC 2009
On Mon Jun 8 23:22:34 2009, Peter Saint-Andre wrote:
> "Don't send my [outbound] presence" or "Don't send me [inbound]
> presence" or both? Based on previous discussions, I assume the
> > - 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
> 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
> becomes too big, then flush the cache and probe if needed).
A probe will send at least one presence stanza per contact in the
roster. Sensible buffering of presence - dropping intermediate
presence - will also do this. So I don't think probes are a good
option, especially as you'd then have to buffer the responses up to
get the compression advantage that we're after here.
> > So <presence/> gets buffered until either a <message/>, or an
> > needs sending.
> Needs sending inbound to the client? I assume so, just making sure.
That'd be the idea.
> > The client can flush the pending presence in a number of
> > ways, the most obvious one being simple using a XEP-0199 ping -
> > response being quite sufficient to flush the presence down.
> What exactly do you mean by "flush the presence down"? Do you mean
> the server sends updated inbound presence to the client, or that it
> empties the server-side cache?
Let me give a concrete example - in our implementation, stanzas are
written to a buffer, and at some point, a function called
xmpp_flush() is called, which runs the buffer through XEP-0138, TLS,
etc, and actually calls the write() system call to send the data over
In a simple implementation of this presence hushing thing, we simply
wouldn't call xmpp_flush() if there were only presence stanzas in
that buffer, unless it got "quite big". (We could be cleverer, and
remove presence stanzas that were overtaken by events, etc, but
> 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
> receive a phone call (Jingle invite) or a "useful" message (for some
> value of "useful" -- e.g., perhaps not some random, low-priority
Phone calls are easy enough, being <iq/>.
I would say that I'm going to push back on anything needing XPath
evaluations on every stanza - I don't think any server implementor
wants that - but switching off headline type messages seems
> > Now, the reason I don't think the rest of SIFT helps is that I'm
> > convinced that much "unsolicited" <iq/> traffic actually happens,
> How about unsoliticited <message/> traffic? I'm not talking only
> PEP stuff here, but news feeds, chatroom invitations, roster item
> exchange messages, etc. I grant that it's difficult to sort through
> those, but that's what something like SIFT would give you. However,
> perhaps we get the biggest bang for the buck with presence only.
I have to admit, aside from headline type messages, I'm not clear
what using caps to signal intent misses out.
For maximal cleverness, one could conceive a server which filtered
out unsupported or unrequested stanzas based on caps, but I'm not
sure I'd want to do that.
> > because well-behaved actors, at least, will check the disco#info
> > 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
Right - it might well be worth using *different* caps for people in
your roster vs MUC, etc, though.
> > vcards from MUC (please, folks, fix
> > those),
> What *exactly* needs fixing here? Separate thread, please. :)
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