[OpenSER-Devel] SF.net SVN: openser: [3972] trunk

[Daniel-Constantin Mierla]

On 04/03/08 23:47, Dan Pascu wrote:
> On Thursday 03 April 2008, Daniel-Constantin Mierla wrote:
>   
>> to understand from here that developers of  openser should provide
>> flexibility and have the column names as parameters but not the same
>> for other applications (being a bit nasty this time ... ;-) )
>>     
>
> There was no mention that those application are configurable or not
I didn't say it was such mention. It is a personal conclusion. If you 
look back in time, we faced two contradictory issue:
- being too much flexible, making things too complex and hard to 
understand some time
- not being flexible enough, by letting other systems to take care of 
stuff they can solve

One should not take care about column names as long as there are views 
support, but some do not like it this way, and should be able to have 
customizable column names. And do not take anything personally, I am 
among these. And this is just one example.

There are many things to be changed and better if done somehow else, but 
you know better than others that each has priorities and time 
constraints. openser cannot solve all the issues for everybody and be 
the ideal solution.

>  and 
> even if it was, quite frankly, I do not see the point you try to make 
> here. Openser may need to work with preexisting subscriber databases,
There are views and connectors, if you want to get to the root. I do not 
see as developer why to think about what one can have in the private 
systems, and that is far more unpredictable than db keywords.
>  
> while an application that reads and displays sip traces is made for one 
> sole purpose, and it doesn't have to work with something else than 
> openser.
and siptrace does it for openser only, but openser has many db types 
behind, and the code should obey to this architecture. Everyone shall 
take in consideration that.

The role here is to find the most convenient solution for everybody. I 
do want to have the public openser tools working and the oracle database 
support integrated, I am accepting any solution that make these things 
happy and what was proposed so far, with patch given, was renaming the 
column, considering the module provides enough flexibility to work with 
the old structure at the expense of one extra config line in openser.

>  If it has, then I'm sure it may have configurable database 
> access to work with multiple data sources.
>   
In the same context, am pretty much sure that we can delete all the db 
modules but unixodbc, get rid of DB API layer and migrate to use ODBC 
API directly in the code. But who is fixing unixodbc issues?

Daniel

-- 
http://www.asipto.com