We have a project where we’d like to integrate ejabberd with an existing
system based on MongoDB.

I’ve seen approaches to running ejabberd over Mongo which involve an
ODBC wrapper, but I’d like to avoid that—it strikes me as inefficient
(and complicated!), and involves using a highly relational schema in
Mongo, which it isn’t well-suited for.

Instead, we’d like to write a new gen_storage backend, implementing the
same API as gen_storage_odbc and translating queries to native Mongo
calls.

That part seems fairly easy, but there are places in the ejabberd code
that explicitly check backend names (e.g. gen_storage:create_table, and
one place in gen_storage:table_info which looks like a bug).

I also notice that mod_pubsub seems to have two completely parallel
implementations, one for mnesia and one for odbc, which duplicate code
rather than abstracting backend calls out via gen_storage. I can’t
immediately see a reason for this.

So, we’d like to write a patch for ejabberd which does the following:

- Minor tweaks to gen_storage to allow custom backends in places like
create_table

- Minor tweaks to other hardcoded backend references (e.g.
mod_roster:update_table) to allow the same.

- Major refactoring of mod_pubsub to abstract out storage calls, either
via gen_storage or by splitting it into e.g. mod_pubsub,
mod_pubsub_storage_mnesia, and mod_pubsub_storage_odbc, and then
allowing alternate backends to be injected.

If we do this, what are our chances of getting it merged into trunk? Are
there major problems that I haven’t anticipated, or existing work in the
same direction?