[sr-dev] New module DMQ_SYNC and patch for DMQ

[Daniel-Constantin Mierla]

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 at bks.tv
> <mailto:rybkin.a at 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
>     JID: rybkin.a at bks.tv <mailto:rybkin.a at bks.tv>
>     E-Mail: rybkin.a at bks.tv <mailto:rybkin.a at bks.tv>
>
>     2014-10-28 16:46 GMT+03:00 Alex Hermann <alex at speakup.nl
>     <mailto:alex at 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 at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
> www.sipcentric.com <http://www.sipcentric.com/>
>
> Follow us on twitter @sipcentric <http://twitter.com/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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141029/edda850d/attachment-0001.html>