Hello, for fairness and a more complete picture, I should have mentioned that I am somehow the first that broke into module specific backend with topos and topos_redis. In that case, I was also guided by the goals of squeezing what ever can be exploited in terms of performances from Redis backend, given that topology hiding with stripping/adding back headers for all SIP traffic needs be be (ideally) very fast.
The topos module had DB API support and can be used with mysql, postgres, etc ... topos_redis was added as an alternative to use directly a Redis server. However, topis_redis is not on top of DB API, therefore a name not related to it at all. Cheers, Daniel On 21.02.18 10:48, Alex Balashov wrote: > Hi, > > I have not dived into the technical specifics deeply or examined the > innards of db_redis, so this is really shooting from the hip: > > I can appreciate the very legitimate dilemma here. However, in general I > would advocate for keeping all DB connectors generic. > > Although I understand that there are some punishing generalisations and > contortions required to shoehorn particular modules' schematic > requirements into the more general DB API, there is a lot of value in > the highly consistent database agnosticism afforded by doing this. This > is similar to the trade-offs involved in using ORMs a lot of the time. > As things currently stand, it is possible to use any db_* backend with > Kamailio in a highly interchangeable way, and not many DB-backed systems > can truly deliver on that promise. Kamailio shines as a rare exception. > > The other problem is that the leaky / inconsistent abstractions involved > in more Byzantine DB module choices will be confusing to users, most of > whom are not software engineers presumably and will not easily > understand the difference between a module-specific DB connector and a > generic one. It will also lead to some needless duplication of effort > and possibly lopsided support for one or the other pathway to the > database in cases where a module has both generic and module-specific > connector support. > > Finally, although I understand that third parties contributing modules > are charged with maintaining them, it seems to be a practical effect > that you (Daniel) and others are dragged into maintaining orphaned or > semi-orphaned modules, or the "plumbing" dependencies that they generate > within common code. The project already has a bewildering array of > modules, all moving at different speeds, having different levels of > sophistication and so forth. Now, I know that I have always taken a more > conservative position on matters of curation of third-party > contributions relative to the implicit maintenance burden, and we may > differ on that, but I think pouring more fuel on that fire by splicing > in multiple levels of DB abstraction for some modules will create > unnecessary maintenance headaches without the corresponding pay-off. > > Whether the database is traditional relational or schemaless, I don't > think it's unreasonable to ask that any DB-backed module adhere to the > common DB API and use those mechanisms to interact with the DB. It just > leads to more consistent, maintainable code and more predictable > outcomes, while providing a level of flexibility people have come to > expect with the RDBM-backed modules. > > -- Alex > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev