24 Jun
2009
24 Jun
'09
11:27 a.m.
On 06/24/2009 05:06 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
yes, this is a long term goal. But that cannot be achieved now, so we
have overlapping modules, overlapping tools, overlapping table names but
different structure. The development and contributions are and will be
done only to sip-router.org repository.
Complete module integration will take some time, cannot be done up to
autumn and some are very delicate as people have tools relaying on
current db structure of each project -- just for example, kamctl cannot
handle ser db, serctl cannot handle kamailio db. Of course you can mix
modules from both project, because you have the insights, but for a
public release it will be a nightmare from support point of view.
So, to conclude, I am talking about public releases, not something (us
as developers or very familiar users) build internally and use in our
products/solutions. So when new users come, we can give them straight
and clear answers.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
We are talking about this particular project
hosted by sip-router.org
which had no release so far, but needs an identity. Next version of
kamailio will still be named kamailio and include the modules inherited
from kamailio, probably including some modules from ser as well.
this is news to me. i'm pretty sure that there was a plan that 1.5 will
be the last version of kamailio, but haven't checked mail archives.
if that will not be the case, it would have made no sense to start
putting all kinds of migration documentation there. we should have
simply kept on using the k site and update the docs there.
if you plan to keep on using name kamailio, then you can do whatever
name changes you want there when you package next version of kamailio.
i'm not going to be any part of that, but keep on using and contributing
only to sip router project.
regarding modules, everyone can pick from modules subdirs whatever
modules they like to use. over time it would make sense to try to unite
k and ser modules when feasible in order to save maintenance resources.