TODO

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.

==========