Hi, given the fact, that we do a lot of "non-sip" related stuff with Kamailio (we are using Kamailio as a Diameter HSS, Diameter Charging-Server (OCS), Diameter Routing-Agent (DRA)), I would also vote for number (2):
> 2) remove the function export from the core and export one with the same > name from the corex module Thanks, Carsten -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Millerntorplatz 1 20359 Hamburg / Germany http://www.ng-voice.com mailto:cars...@ng-voice.com Office +49 40 5247593-40 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/ Am Mi., 19. Dez. 2018 um 12:55 Uhr schrieb YAS0 CANER < caner_y...@hotmail.com>: > TmEXIT , kEXIT and corEXIT is failed 😊 > ------------------------------ > *From:* sr-users <sr-users-boun...@lists.kamailio.org> on behalf of Olle > E. Johansson <o...@edvina.net> > *Sent:* Wednesday, December 19, 2018 2:38 PM > *To:* Daniel-Constantin Mierla > *Cc:* Kamailio (SER) - Development Mailing List; Kamailio (SER) - Users > Mailing List > *Subject:* Re: [SR-Users] [sr-dev] RFC: updates to some core functions > > > > > 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 > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users