> On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla <mico...@gmail.com> wrote: > > > On 19.12.18 09:47, Olle E. Johansson wrote: >> >>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla <mico...@gmail.com> >>> wrote: >>> >>> corex module was added to hold the functions that otherwise would be >>> more or less "in the core", like those that were updated to support >>> variables in the parameters, so this is the one to take the place of >>> core in regard to exporting functions. >>> >>> tmx was added because tm module became very big, but also to try to >>> separate a bit between transaction management code and some functions in >>> top of it, in the way that tmx can work only with exported api by tm, so >>> if one adds a function there doesn't get access to all internals of >>> transaction and it is safer not to mess up things there. It is more or >>> less like usrloc and registrar, usrloc does internal management of >>> location records, registrar is the interface to configuration file (but >>> there are other modules on top of usrloc, like pua_usrloc, dmq_usrloc, ...). >>> >>> kex is the one that collected some functions that use to be in kamailio >>> (or better said openser at that time) but not in ser during 2005-2008 >>> and can be a module that be analyzed to see if can be merged into other >>> modules. A big chunk of it used to be related to MI commands, but as we >>> got rid of MI, might be easier now to split parts of it and relocate. >>> >> Ok, so removing kex is a good first step for the coming release. >> >> It’s really hard explaining TMX and TM for new Kamailians. > > We can add a note at the top of docs for each of these modules to refer > to the other. > > On the other hand, I do not like to have a huge module. It is not > suitable for small embedded systems. Also, there are other modules using > the tm api, so it is a common approach. The tmx is exporting mostly > functions at higher level of transaction interaction, one can build a > transaction stateful sip routing without it, only using tm. > Damn it. My campaign for exit of the x modules just died. Sad story.
Thanks for all the responses! /O > Cheers, > Daniel > >> >> /O :-) >> >>> Cheers, >>> Daniel >>> >>> On 19.12.18 09:25, Olle E. Johansson wrote: >>>> Going back one step, are there any reasons to keep tmx, kex and corex >>>> modules at all? >>>> >>>> At this point in the project I think many of the functions should be >>>> merged into >>>> the main modules and core. >>>> >>>> If I remember correctly, they exist because of a multi-brand history that >>>> is not >>>> really the case any more. >>>> >>>> /O >>>> “The campaign to remove Kamailio extensions to Kamailio” >>>> >>>> >>>>> On 19 Dec 2018, at 09:11, Henning Westerholt <h...@kamailio.org> wrote: >>>>> >>>>> Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov: >>>>>> I prefer second way. Without any duplication. >>>>>> For old configs branches 4.4, 5.0, 5.1 is always available. >>>>> Hello, >>>>> >>>>> I would prefer also the second way, for the same reason: less duplicated >>>>> functions. >>>>> >>>>> Best regards, >>>>> >>>>> Henning >>>>> >>>>> >>>>>> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla >>>>>> <mico...@gmail.com>: >>>>>>> Hello, >>>>>>> >>>>>>> it was brought into discussions several times in the past about core >>>>>>> functions not accepting variables in the parameters. I think it is time >>>>>>> to update them during the 5.3 release development. For few of them, I >>>>>>> added in the past some alternative function in the corex module (e.g., >>>>>>> force_send_socket() in core and set_send_socket() in corex module). >>>>>>> >>>>>>> So, I see two options: >>>>>>> >>>>>>> 1) add a function with similar name in corex module and same behaviour >>>>>>> like the one from core >>>>>>> >>>>>>> 2) remove the function export from the core and export one with the same >>>>>>> name from the corex module >>>>>>> >>>>>>> First one will ensure that configs using the functions right now keep >>>>>>> working without any update. >>>>>>> >>>>>>> The second one will be better in long term from the point of >>>>>>> documentation (no duplicated docs), but there might be few cases that >>>>>>> would require updates in the config -- iirc, there are some functions >>>>>>> that can get special tokens in the parameters (like forward(uri:host, >>>>>>> uri:port)), they will get an equivalent with variables, but old config >>>>>>> will not be compatible. >>>>>>> >>>>>>> Obviously the reason for this email is to ask the developers and users >>>>>>> what would be the preferred way from own point of view. >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>> -- >>>>> Henning Westerholt - https://skalatan.de/blog/ >>>>> Kamailio services - https://skalatan.de/services >>>>> Kamailio security assessment - https://skalatan.de/de/assessment >>>>> >>>>> _______________________________________________ >>>>> Kamailio (SER) - Development Mailing List >>>>> sr-...@lists.kamailio.org >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>> _______________________________________________ >>>> Kamailio (SER) - Development Mailing List >>>> sr-...@lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>> -- >>> Daniel-Constantin Mierla -- www.asipto.com >>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >>> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com >>> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in >>> Washington, DC, USA -- www.asipto.com >>> > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in > Washington, DC, USA -- www.asipto.com > _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users