Hello,
probably i.e., in the readme should have been e.g., since that is
intended to be just an example, not a different description.
Now, iirc, calling of pres_refresh_watchers() is not because of an
update to presentity state, but xcap changes with pres-rules can result
in a different presentation of published document -- you can specify
about what and how to present to watchers. Updating the watchers can be
due to removing a rule that blocks it. Note that all the xcap operations
can be with partial content.
Cheers,
Daniel
On 10/1/11 1:32 PM, Juha Heinanen wrote:
presence/README has:
4.4. pres_refresh_watchers(uri, event, type)
...
* type - it distinguishes between the two different types of events
that can trigger the refresh, depending on its value:
+ 0 - a change in watchers authentication.
+ 1 - a statical update in published state (either through
direct update in db table or by modifying the pidf
manipulation document, if pidf_manipulation parameter is set).
4.5. pres_update_watchers(uri, event)
The function can be used in configuration to triger updates to watchers
status if a change in watchers authorization state occurred (i.e.,
updates of xcap documents change state from pending to active).
then in xcap_server/README there is an example where these two functions
are used:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules")
{
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
exit;
break;
case "GET":
xcaps_get("$var(uri)", "$hu");
exit;
break;
case "DELETE":
xcaps_del("$var(uri)", "$hu");
if($xcapuri(u=>auid)=~"pres-rules")
{
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
exit;
break;
}
in PUT and DELETE, why type param value is 1 in pres_refresh_watchers
calls, because xcap operations do not update published state of
presentity?
in DELETE, why pres_update_watchers is called, because xcap delete
cannot change watchers status from pending to active?
-- juha
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
