| 1 | TODO for 2.0 |
|---|
| 2 | ------------ |
|---|
| 3 | |
|---|
| 4 | Roster templates may not be working properly (esp. with multiple items). |
|---|
| 5 | Check and fix if necessary. |
|---|
| 6 | |
|---|
| 7 | |
|---|
| 8 | Make sure that available presence in response to a s10n accept arrives |
|---|
| 9 | after the type='subscribed' (see chat with Nathan Walp) |
|---|
| 10 | |
|---|
| 11 | |
|---|
| 12 | c2s may not be properly detecting client connections dropping. I feel |
|---|
| 13 | like I've checked this numerous times, so check once more, once and for |
|---|
| 14 | all. |
|---|
| 15 | |
|---|
| 16 | |
|---|
| 17 | Modify user-load chain calls to indicate if the user is being loaded for |
|---|
| 18 | a session, or just for delivery. Don't load rosters (and other large |
|---|
| 19 | things) in that case. |
|---|
| 20 | |
|---|
| 21 | ========== |
|---|
| 22 | |
|---|
| 23 | The requirement for this is that large presence broadcasts (for the |
|---|
| 24 | same host) result in many users being loaded for delivery, only to |
|---|
| 25 | find out that they have no sessions online, and then being unloaded |
|---|
| 26 | again. If we could stop some parts of the user data being loaded when |
|---|
| 27 | the user is loaded only for packet delivery, then the overhead could |
|---|
| 28 | be kept to a minimum. |
|---|
| 29 | |
|---|
| 30 | Privacy lists make this hard, if not impossible. Privacy lists must be |
|---|
| 31 | loaded at packet delivery time, because the user may have a default |
|---|
| 32 | list. That default list may have rules based on roster group, so the |
|---|
| 33 | roster must be loaded. |
|---|
| 34 | |
|---|
| 35 | A partial solution might be to have a module that runs in in-router |
|---|
| 36 | before mod_privacy, that watches for presence packets and drops them |
|---|
| 37 | if the user is not online. This should work, because even if the |
|---|
| 38 | presence packet was allowed by the default privacy list, it'll get |
|---|
| 39 | dropped anyway because mod_deliver would find later that there are no |
|---|
| 40 | sessions online. |
|---|
| 41 | |
|---|
| 42 | This doesn't fix the problem completely though because mod_privacy |
|---|
| 43 | needs the user's roster loaded in order to process a default list with |
|---|
| 44 | rules based on roster group. There's no way for mod_privacy to call |
|---|
| 45 | into mod_roster to get it to load the roster on demand. |
|---|
| 46 | |
|---|
| 47 | Long term, there's a couple of possibilities. In general, I believe |
|---|
| 48 | its reasonable to either have all user data loaded, or none of it - |
|---|
| 49 | anything in between requires a measure of the "importance" of certain |
|---|
| 50 | data (which doesn't scale and is highly subjective) or a on-demand |
|---|
| 51 | system of loading data, which requires dependency graphs and |
|---|
| 52 | inter-module communication. This stuff isn't impossible, but I don't |
|---|
| 53 | want to go there if I can help it. |
|---|
| 54 | |
|---|
| 55 | It might be better to simply implement a (configurable) delay before |
|---|
| 56 | unused user data is unloaded. This will still mean that the first |
|---|
| 57 | presence broadcast can get sluggish, but after this things should chug |
|---|
| 58 | along nicely. |
|---|
| 59 | |
|---|
| 60 | A patch for the partial soltuion mentioned above has been implemented, |
|---|
| 61 | as _presence_in_router(). This is not a complete fix, but does |
|---|
| 62 | workaround the most common case. |
|---|
| 63 | |
|---|
| 64 | ========== |
|---|
