On Nov 30, 2012, at 10:17 AM, Quanah Gibson-Mount quanah@zimbra.com wrote:

However, "mdb.h" seems to be common:

I suggest it be installed so it included as <openldap/mdb.h>.

-- Kurt

On Nov 30, 2012, at 2:13 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:

--On Friday, November 30, 2012 2:04 PM -0800 Kurt Zeilenga kurt@OpenLDAP.org wrote:

...

On Nov 30, 2012, at 10:17 AM, Quanah Gibson-Mount quanah@zimbra.com wrote:

...

However, "mdb.h" seems to be common:

I suggest it be installed so it included as <openldap/mdb.h>.

Hm, that would imply MDB is tied to OpenLDAP, to me.

Given this is being discussed on this list, it seems tied to the OpenLDAP Project and hence putting it an openldap/ subdirectory seems sensible to me.

OpenLDAP doesn't necessarily mean OpenLDAP Software package (which this is contained in), it can just as well refer various other software packages of the project.

Which, as there are a growing number of project with MDB support, would seem to be inaccurate. I rather see it renamed to something unique, like lmdb.h, which also would match the library rename.

Trying to keep individual headers unique across multiple independent projects doesn't work well. If various others use this header, they might include a copy of the header (and library) in their distributions. So one might have say foo/lmdb.h and openldap/lmdb.h, where maybe they are the same, differ slightly, or are completely different headers.

-- Kurt

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

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

-- Hallvard

Gavin Henry wrote:

...

What about just memorydb or memdb?

http://www.openldap.org/lists/openldap-devel/201111/msg00064.html

Apologies.

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.

Quanah Gibson-Mount writes: [About name clashes with MDB Tools]

The only place I can think this could cause an issue would be Debian (and then Ubuntu). They load all library symbols into a shared address space used by every user, including root. This has caused me endless nightmare in the past with conflicting symbols between my own LDAP libraries and the debian system libraries when thinks like nss_ldap were in use (loading the system libraries).

mdb_open and mdb_close are the name clashes I see without asking the compiler (I'd need to install glib). We could rename those to mdb_dbi_<open/close>. Perhaps combined with the compat macros below:

My reasons for preferring a full rename had little to with MDB tools. If you'd have done that if not for compat issues: A transition isn't hard, merely ugly. Something like this at the *beginning* of lmdb.h - or in lmdb_compat.h, which lmdb.h includes #if (LMDB_COMPAT_2012):

#if (LMDB_COMPAT_2012) /* "2012" to distinguish from future compat macros */ /* First, symbols needing only source-level compat */ # define MDB_NOSUBDIR LMDB_NOSUBDIR # ... /* Next, binary compat. External names, types+enums for debuggers. */ # if (LMDB_COMPAT_2012) > 0 /* Old source file vs. new liblmdb library */ # define mdb_open lmdb_open /* Not mdb_open(...). "&mdb_open" would fail. */ # ... # else /* (LMDB_COMPAT_2012) < 0: New source file vs. old libmdb library */ # define lmdb_open mdb_open /* turns later lmdb_open() decl into mdb_open */ # ... # endif #endif /* LMDB_COMPAT_2012 */

/* Then the "real" lmdb.h */ #define MDB_NOSUBDIR 0x4000 ... int lmdb_open(/*...*/); ...

For that matter, an optionally installed mdb.h could do

#ifndef LMDB_COMPAT_2012 # define LMDB_COMPAT_2012 1 #endif #include "lmdb.h"

I'm not going to be terribly disappointed if this hack is turned down:-)