[SR-Users] [sr-dev] RFC: updates to some core functions

[Daniel-Constantin Mierla]

On 19.12.18 09:47, Olle E. Johansson wrote:
>
>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla <miconda at 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.

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