TODO for 2.0
------------
Roster templates may not be working properly (esp. with multiple items).
Check and fix if necessary.
Make sure that available presence in response to a s10n accept arrives
after the type='subscribed' (see chat with Nathan Walp)
c2s may not be properly detecting client connections dropping. I feel
like I've checked this numerous times, so check once more, once and for
all.
Modify user-load chain calls to indicate if the user is being loaded for
a session, or just for delivery. Don't load rosters (and other large
things) in that case.
==========
The requirement for this is that large presence broadcasts (for the
same host) result in many users being loaded for delivery, only to
find out that they have no sessions online, and then being unloaded
again. If we could stop some parts of the user data being loaded when
the user is loaded only for packet delivery, then the overhead could
be kept to a minimum.
Privacy lists make this hard, if not impossible. Privacy lists must be
loaded at packet delivery time, because the user may have a default
list. That default list may have rules based on roster group, so the
roster must be loaded.
A partial solution might be to have a module that runs in in-router
before mod_privacy, that watches for presence packets and drops them
if the user is not online. This should work, because even if the
presence packet was allowed by the default privacy list, it'll get
dropped anyway because mod_deliver would find later that there are no
sessions online.
This doesn't fix the problem completely though because mod_privacy
needs the user's roster loaded in order to process a default list with
rules based on roster group. There's no way for mod_privacy to call
into mod_roster to get it to load the roster on demand.
Long term, there's a couple of possibilities. In general, I believe
its reasonable to either have all user data loaded, or none of it -
anything in between requires a measure of the "importance" of certain
data (which doesn't scale and is highly subjective) or a on-demand
system of loading data, which requires dependency graphs and
inter-module communication. This stuff isn't impossible, but I don't
want to go there if I can help it.
It might be better to simply implement a (configurable) delay before
unused user data is unloaded. This will still mean that the first
presence broadcast can get sluggish, but after this things should chug
along nicely.
A patch for the partial soltuion mentioned above has been implemented,
as _presence_in_router(). This is not a complete fix, but does
workaround the most common case.
==========