19 Dec
2018
19 Dec
'18
2:38 p.m.
On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 19.12.18 09:47, Olle E. Johansson wrote:
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
On 19 Dec 2018, at 09:41, Daniel-Constantin
Mierla <miconda(a)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. 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(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
>
--
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