24 Aug
2009
24 Aug
'09
3:54 p.m.
On 24.08.2009 15:08 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
if you refer to merging "duplicated" modules, could not be a solution
anyhow. In the past, there were some events generating hot discussions
when trying to force/limit to one way of doing things.
The preliminary discussions for sip router project concluded that there
must be freedom of contributors with fair control of original developer.
Core, tm are sensitive parts and so called "common layer" where any
piece of code getting in is carefully reviewed.
Otherwise, if there is a conflict in licensing, between developers of
same piece of code, creating a new module/library is the way to go. This
does not mean everyone can spin off new modules, but if the contribution
is relevant, has support from community members, it must get in.
I see no reason of having modules for same functionality (e.g., say
authentication) as long as each such module has maintainers. Time should
prove which is better and obsolete the others, but also, each could be
more suitable for a particular case.
Just as a different example, sqlops plus some scripting could obsolete
most of db-connected modules - auth_db, alias_db, speeddial, uri_db,
a.s.o, but doing so is not at all a good decision.
I am personally aware of companies using Kamailio
with several
millions of subscribers, using kamailio database schema. Also, I am
aware of companies having more or less same level of subscriber base
using SER database schema. All have additional tools for management,
integration with third-party application, a.s.o. Do you think that
saying "hey, you were the unlucky bastard because we are going to
drop tomorrow the database schema you are using" is the solution?
That's true.
We can say that there should be one unified code body all we want, but, at the very least we need to
acknowledge that
the problem is not nearly as simple as it looks on the surface.
Nothing is simple :-) . Also, I admit that any integration work rises
controversy, which may create some degree of confusion. But all
discussions were constructive so far, nothing was dismissed and the way
things blended so far proves the flexibility level we achieved: keep the
core and tm small and stable, build around with modules and libraries so
that the impact is minimal for those not using the stuff that just got in.
From my point of view, integration went smooth, but with higher work
volume that anticipated, since both projects really had a lot of new
features (some better documented, some not).
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/