[Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing

[Daniel-Constantin Mierla]

On 24.08.2009 15:08 Uhr, Alex Balashov wrote:
> Daniel-Constantin Mierla wrote:
>
>> 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

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.

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