Quanah Gibson-Mount wrote:
--On Saturday, December 01, 2012 8:05 PM +0100 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
Howard Chu writes:
This is basically a continuation of this thread http://www.openldap.org/lists/openldap-devel/201111/msg00063.html
I think liblmdb for the name of the library file is fine. Do we need to change any other instances of "mdb" as well, or can we just let them slide?
Need, no, but my vote is for changing it throughout. Failing that, changing the user-visible stuff. File extensions, program names, documentation.
For consistency, and taking the opportunity to escape the Goolge(mdb) hits for Microsoft's MDB. "back-mdb" doesn't hit those, but "database mdb" and the .mdb file extension do.
Also, what is it going to be called now? It now seems to be the Lightning mdb -- as opposed to the Microsoft mdb? Yet an mdb isn't some well-established term, even if we've talked about it a lot lately. So I'm not exactly sure what the stand-alone name "mdb" is needed for at this point. Unless that can be fixed by just phrasing things a bit differenlty than I just did.
I don't see the point here as renaming MDB into something new like lightning db or memory db. I see the point as simply avoiding conflicts. I would keep back-mdb, I would keep the mdb extension. The library clash issue has been fixed by renaming it to liblmdb. For Kurt's point, perhaps <lmdb/mdb.h>, so that the directory resembles the library name.
I don't think we need any <foo/*db.h> naming structure. We *must* rename the library because libmdb.* clashes with an existing package. Simply moving the header file to a subdirectory does nothing to solve the library naming clash. Since we're using liblmdb for the library name now, it would be most consistent to also use <lmdb.h> for the header file. I don't see any value in using <xxx/lmdb.h>.
I'm calling it Lightning because I think it's a suitable name, and the 'l' ought to stand for something.
I'm fine with keeping back-mdb named as it is.
I'm not too keen on renaming all of the actual library symbols, since there are already a couple of other projects that have adopted mdb in its earlier form. But certainly, if we're going to do so, we need to do it before it gets even wider adoption. Again, because of the MDB Tools project's libmdb, we probably should do so. But on the flip side, that project hasn't been touched since 2004, so it seems unlikely to me that anyone is ever going to write code using both their library and ours at the same time.