2010/9/30 Daniel-Constantin Mierla miconda@gmail.com:
I wonder if a delete can change the status of watcher. Usually is translation from none to pending to active, but can be other way around triggered by xcap operation?
In OMA specs *any* change (PUT/DELETE) in resource-lists document must trigger a reload of pres-rules and other applications including references to lists in 'resource-lists'. The same in 'pres-rules' document, sure.
If for example Bob is included in <list id="friends> and such list is referred by <list id="oma_buddies"> and 'oma_buddies' is referred by a rule in pres-rules with action 'allow', then removing Bob from <list id="friends"> requires the *complete* (UGLY) pres-rules to be re-calculated so Bob's subscription status would change from "active" to "terminated".
Now to demostrate how ugly is all this stuff, let imagine you want to temporally block Bob (so he cannot see your current real presence status). According to OMA specs (and there are no other specs):
1) First you should do a partial DELETE operation in 'resource-list' to remove Bob uri from your granted <list>.
2) Later you should do a partial PUT operation in 'resource-lists' to include Bob in a <list id="oma_polite_blocked"> (or something similar).
Oppps, problem! After step 1 the presence server should *terminate* the subscription dialog with you (the watcher) so you receive a NOTIFY with "Subscription-Status: terminated;reason=rejected". Then it's *up to you* to subscribe to Bob again or not.
Imagine you subscribe again to Bob's presence upon receipt of the NOTIFY (but before the above step 2). Then your SUSBCRIBE would be rejected again. Will you try *again* a new SUSBCRIBE? for how long? After step 2, if you send a new SUBSCRIBE then the server will accept your subscription but notify you with false presence status (or no info at all) as you are polite-blocked.
Obviously this design is ugly. In contrast, in XMPP there is like an API to "authorize"/"desauthorize" a contact, "block" him... you must not deal with tedious XML files for *all*, neither you need to expect that the presence server and all your UA's (same AoR) interpret the whole XML documents in the same way (bob is included in "oma_granted" list but he is also included in 'pres-rules' document as a separate blocked entry, should I understand he is blocked or allowed? will the presence server understand the same as my UA?).
Also, in XMPP a change in your buddylist doesn't require the presence server to re-compute all the permissions of all your watchers.
Well, coming back to the original question: yes, any incremental/total change (PUT/DELETE) in pres-rules or resource-lists document should trigger a complete reload of watchers permissions. Also, the RLS application uses a reference to a <list> into resource-lists, so if a item in such list is modified the RLs should recompute the list of AoR's it must subscribe in behalf of the user (so ugly all of this...).
Regards.