I prefer second way. Without any duplication. For old configs branches 4.4, 5.0, 5.1 is always available.

ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla <miconda(a)gmail.com>om>: > 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

On 19 Dec 2018, at 09:11, Henning Westerholt <hw(a)kamailio.org> wrote: Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov: Hello, I would prefer also the second way, for the same reason: less

functions. Best regards, Henning > ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla

>> Hello, >> >> it was brought into discussions several times in the past about core >> functions not accepting variables in the parameters. I think it is

>> 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

-- 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-dev(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

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” _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Ok, so removing kex is a good first step for the coming release. It’s really hard explaining TMX and TM for new Kamailians.

/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 <hw(a)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 <miconda(a)gmail.com>om>: >>>>> 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-dev(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> _______________________________________________ >> Kamailio (SER) - Development Mailing List >> sr-dev(a)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 >