+1 for option #2
On Wed, Dec 19, 2018 at 04:35 Carsten Bock <[email protected]> wrote: > 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:[email protected] > > 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 < > [email protected]>: > >> TmEXIT , kEXIT and corEXIT is failed 😊 >> ------------------------------ >> *From:* sr-users <[email protected]> on behalf of Olle >> E. Johansson <[email protected]> >> *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 <[email protected]> >> wrote: >> > >> > >> > On 19.12.18 09:47, Olle E. Johansson wrote: >> >> >> >>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla <[email protected]> >> 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 <[email protected]> >> 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 < >> [email protected]>: >> >>>>>>> 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 >> >>>>> [email protected] >> >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> >>>> _______________________________________________ >> >>>> Kamailio (SER) - Development Mailing List >> >>>> [email protected] >> >>>> 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 >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
