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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
