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 _______________________________________________ Devel mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/devel
