I was actually thinking of it, but couldn't get to a clear conclusion before ...

Overall, I am not sure if making white or black is the best. I see it more of a per case situation.

For example, usrloc is a standalone component by itself, with registrar being the interface to kamailio.cfg, then pua_usrloc or pua_reginfo being the presence events publishing. Being such a component used in various directions, I think it should stay rather independent, not getting extra stuff inside, but other components can be built on top of its exported API.

On the other hand, just adding a new module for each other module that wants to notify via dmq could be an unnecessary overhead.

So, at this moment, I would say, if the module has everything that is needed exported via API, the dmq can be done as separate module. Also, if the module is very sensitive, I would suggest the same approach (e.g., I wouldn't like to see it inside tm module, if someone thinks of dmq-ing transactions, but rather a separate module or part of tmx).

Cheers,
Daniel


On 29/10/14 19:38, Charles Chance wrote:
Maybe others can offer their advice as to which is the preferred way to go?



On 28 October 2014 14:40, Andrey Rybkin <rybkin.a@bks.tv> wrote:
Thought about to add this functionality to the module. If this approach seems to be more correct, then I can move my code in a module, but, in my opinion, it is not very correct.
________________________________
Andrey Rybkin
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex@speakup.nl>:
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
> Module DMQ_SYNC:
>   The module add replication between multiple servers via DMQ module.
>    Currently only usrloc replications.

I think some decision should be made on where syncing code should be placed.
The htable module has dmq sync integrated, now you introduce a module
dedicated to syncing via dmq.

I have no strong preference, but am against different implementations
depending on the module. So i would prefer either dmq-sync integrated into
each module, or one dmq_sync module. Not a combination of both.


> TODO:
>  1.  dialog replications.
>  2.  bugfixes.
>
> Patch fo DMQ:
>  1. add  find_dmq_node_uri function  to API
>      dmq_node_t* find_dmq_node_uri(str* uri)

>  2. add  init_callback  to  dmq_peer
>      int init_callback()

Except for the broken indenting, this seems equal to my code. If it is mine,
and the code is useful, please cherry-pick the relevant commits so authorship
is retained.

--
Greetings,

Alex Hermann



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev




www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. 

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda