Module: sip-router Branch: master Commit: 59f30b6cbcf25d0ef0f517dad21fa8e711732293 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=59f30b6c...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Apr 22 14:08:51 2009 +0300
* Modules: presence
* Changed name of auth_status function to pres_auth_status. * Fixed and improved example (don't know how to generate new README).
---
modules_k/presence/doc/presence_admin.xml | 15 ++++++++++----- modules_k/presence/presence.c | 6 +++--- 2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/modules_k/presence/doc/presence_admin.xml b/modules_k/presence/doc/presence_admin.xml index 057bc95..f39d676 100644 --- a/modules_k/presence/doc/presence_admin.xml +++ b/modules_k/presence/doc/presence_admin.xml @@ -455,11 +455,11 @@ if(method=="SUBSCRIBE")
<section> <title> - <function moreinfo="none">auth_status(watcher_uri, presentity_uri)</function> + <function moreinfo="none">pres_auth_status(watcher_uri, presentity_uri)</function> </title> <para> The function checks if watcher is authorized to subscribe - presence of presentity. Both watcher_uri and + event 'presence' of presentity. Both watcher_uri and presentity_uri are pseudo variables. Function returns ACTIVE_STATUS, if subscription is allowed and PENDING_STATUS, TERMINATED_STATUS, or WAITING_STATUS @@ -472,11 +472,16 @@ if(method=="SUBSCRIBE") </para>
<example> - <title><function>auth_status</function> usage</title> + <title><function>pres_auth_status</function> usage</title> <programlisting format="linespecific"> ... -if((method=="MESSAGE") && (auth_status("$fu", $ru"))) { - t_relay(); +if (method=="MESSAGE") { + pres_auth_status("$fu", $ru"); + if ($retcode == 1) { + t_relay(); + } else { + send_reply("403", "Forbidden"); + } } ... </programlisting> diff --git a/modules_k/presence/presence.c b/modules_k/presence/presence.c index 9aac54c..703050c 100644 --- a/modules_k/presence/presence.c +++ b/modules_k/presence/presence.c @@ -118,7 +118,7 @@ static struct mi_root* mi_cleanup(struct mi_root* cmd, void* param); static int update_pw_dialogs(subs_t* subs, unsigned int hash_code, subs_t** subs_array); int update_watchers_status(str pres_uri, pres_ev_t* ev, str* rules_doc); static int mi_child_init(void); -static int auth_status(struct sip_msg* _msg, char* _sp1, char* _sp2); +static int pres_auth_status(struct sip_msg* _msg, char* _sp1, char* _sp2);
int counter =0; int pid = 0; @@ -140,7 +140,7 @@ static cmd_export_t cmds[]= {"handle_publish", (cmd_function)handle_publish, 0,fixup_presence,0, REQUEST_ROUTE}, {"handle_publish", (cmd_function)handle_publish, 1,fixup_presence, 0, REQUEST_ROUTE}, {"handle_subscribe",(cmd_function)handle_subscribe,0,fixup_subscribe,0, REQUEST_ROUTE}, - {"auth_status", (cmd_function)auth_status, 2, fixup_pvar_pvar, fixup_free_pvar_pvar, REQUEST_ROUTE}, + {"pres_auth_status", (cmd_function)pres_auth_status, 2, fixup_pvar_pvar, fixup_free_pvar_pvar, REQUEST_ROUTE}, {"bind_presence", (cmd_function)bind_presence, 1, 0, 0, 0}, { 0, 0, 0, 0, 0, 0} }; @@ -1078,7 +1078,7 @@ static int update_pw_dialogs(subs_t* subs, unsigned int hash_code, subs_t** subs return 0; }
-static int auth_status(struct sip_msg* _msg, char* _sp1, char* _sp2) +static int pres_auth_status(struct sip_msg* _msg, char* _sp1, char* _sp2) { pv_spec_t *sp; pv_value_t pv_val;
Hello,
On 04/22/2009 01:11 PM, Juha Heinanen wrote:
Module: sip-router Branch: master Commit: 59f30b6cbcf25d0ef0f517dad21fa8e711732293 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=59f30b6c...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Apr 22 14:08:51 2009 +0300
Modules: presence
Changed name of auth_status function to pres_auth_status.
Fixed and improved example (don't know how to generate new README).
I started two days ago docbook system migrating, there is a wiki page explaining how to add support to generate the docs for K modules: http://sip-router.org/wiki/migration/kamailio-module-docbook
Then some useful commands at: http://sip-router.org/wiki/tutorials/makefile-system
Please add there if someone of you finds new commands.
However, Jan told me he is working on the makefile system for generating the documentation and he will add missing Makefile to K modules, so probably is better you wait a bit and all K modules will be ready.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I started two days ago docbook system migrating, there is a wiki page explaining how to add support to generate the docs for K modules: http://sip-router.org/wiki/migration/kamailio-module-docbook
Then some useful commands at: http://sip-router.org/wiki/tutorials/makefile-system
daniel,
since the Makefile that should be added to each module dir is constant except for module name, it looks like an overkill to me that each module dir should have one. why can't the main Makefile generate module dir Makefile automatically, when a make command is given that makes the module documentation?
-- juha
Hello,
On 04/23/2009 04:34 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I started two days ago docbook system migrating, there is a wiki page explaining how to add support to generate the docs for K modules: http://sip-router.org/wiki/migration/kamailio-module-docbook
Then some useful commands at: http://sip-router.org/wiki/tutorials/makefile-system
daniel,
since the Makefile that should be added to each module dir is constant except for module name, it looks like an overkill to me that each module dir should have one. why can't the main Makefile generate module dir Makefile automatically, when a make command is given that makes the module documentation?
I guess the main reason for having a Makefile for docs per each module is to be able to customize the parameters (different xsl, stylesheet, etc..). Similar as for Makefile of each module sources. I just analyzed what was used in SR and converted some of K modules to use it. IMO, it is more flexible approach atthe expense of having a Makefile there. Also, it seems possible to be able to generate many documents in doc directory if you have different docboox xml files -- not the case for K modules; you can go to doc dir and do make txt|html|xhtml there. Maybe ser guys can comment more...
Cheers, Daniel
Daniel-Constantin Mierla writes:
I guess the main reason for having a Makefile for docs per each module is to be able to customize the parameters (different xsl, stylesheet, etc..). Similar as for Makefile of each module sources. I just analyzed what was used in SR and converted some of K modules to use it. IMO, it is more flexible approach atthe expense of having a Makefile there.
sure it gives more options, but if there is no Makefile in a module dir, then the default one (the one you suggested on wiki page) could be autogenerated.
-- juha
On 04/23/2009 06:26 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess the main reason for having a Makefile for docs per each module is to be able to customize the parameters (different xsl, stylesheet, etc..). Similar as for Makefile of each module sources. I just analyzed what was used in SR and converted some of K modules to use it. IMO, it is more flexible approach atthe expense of having a Makefile there.
sure it gives more options, but if there is no Makefile in a module dir, then the default one (the one you suggested on wiki page) could be autogenerated.
in this way can be extended to modules sources' Makefile. At the end of the day, is one time file addition, as it is with Makefile for modules, so not sure what worth to do now, implement an auto-generator or copy one file -- as I am not a Makefile/shell programmer expert, I prefer copying.
Daniel
Juha,
On 23-04 19:26, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess the main reason for having a Makefile for docs per each module is to be able to customize the parameters (different xsl, stylesheet, etc..). Similar as for Makefile of each module sources. I just analyzed what was used in SR and converted some of K modules to use it. IMO, it is more flexible approach atthe expense of having a Makefile there.
sure it gives more options, but if there is no Makefile in a module dir, then the default one (the one you suggested on wiki page) could be autogenerated.
The advantage of have a makefile in the doc subdirectory is more flexibility, as Daniel explained. We could certainly test if the makefile is missing in a doc subdirectory and then assume that modname.xml is the only docbook source to be processed. But then we would have no chance to clean up the resulting html or txt files on make clean because we would not know if they are generated by docbook or standalone files.
But adding a simple makefile is easy so I added it to all modules.
Jan.
-
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com -
Juha Heinanen