Quanah Gibson-Mount wrote: > Unfortunately, libmdb already exists in modern linux systems as part of > the mdb-tools package. This would be a problematic conflict for getting > MDB packaged in general. As a proposal, how about liblmdb as the new > name? I haven't been able to find any instances of that existing in the > wild. 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?

On Nov 30, 2012, at 10:17 AM, Quanah Gibson-Mount <quanah(a)zimbra.com&gt; wrote: > However, "mdb.h" seems to be common: I suggest it be installed so it included as <openldap/mdb.h>.

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?

What about just memorydb or memdb?

-- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 1 Dec 2012, at 19:21, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no&gt; 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. > > -- > Hallvard >

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'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.