[Standards] SIFT revisited

Dave Cridland 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  
> latter.
> 
> 
Inbound.

> > - 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).

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  
> <iq/>,
> > 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 -  
> 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?

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  
the network.

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  
that's optional).

> 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
> headline).

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  
reasonable.

> > 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.

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  
> 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
> requests.

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. :)

Done.

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