Hi,
I was encouraged on reading the
However further reading led to
Is there any work taking place to abstract the data store needs for ejabberd, or is the accepted practice to produce a mod_pubsub_<variant> (and friends) and continually update these as changes are made on the ejabberd repository?
many thanks,
ian
> a mod_pubsub_ (and
> a mod_pubsub_ (and friends)
BTW, ejabberd 2.1.0 includes the typical mod_pubsub that stores in Mnesia, and a forked mod_pubsub_odbc with stores using ODBC. Both are maintained by the current mod_pubsub maintainer.
> the accepted practice to produce a mod_pubsub_ (and friends) and continually update these as changes are made on the ejabberd repository?
Yes, if you fork mod_pubsub, then you have to periodically merge changes from main repo, as Eric mentioned.
> Is there any work taking place to abstract the data store needs for ejabberd
Yes, it was mentioned many time ago (I can't find the text), that after ejabberd-exmpp merge (which is taking place in ejabberd 3.0.0-alpha), the next major change is to abstract storage code (so it's easier to add new storage methods, and we don't have duplicated modules like mod_roster.erl, mod_roster_odbc.erl.... That may be ejabberd 3.1.0, or 3.5.0 or similar. So don't expect it anytime soon. I've created a ticket to track that:Database storage abstraction layer