21 Feb
2018
21 Feb
'18
12:48 p.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/