On 20 Jan 2011, at 14:57, Adam Kocoloski wrote: > I'd go a little further. I think CouchDB should have two include files: > > include/couch_db.hrl (I'd prefer couch.hrl but I think we might be stuck w/ > this) > src/couch_int.hrl (name is not important) > > The first one would contain all record definitions needed to interact with > CouchDB from Erlang. The second would contain macro definitions and records > that are not supposed to be exported. Moving couch_db.hrl to include/ would > eventually allow other applications to point to couch_db.hrl using the > -include_lib directive instead of specifying the absolute path to the header. > Regards,
I like that approach best. This is all part of a bigger discussion: what does a CouchDB plugin system look like. While technically, you can have plugins today, it is a fairly fragile endeavour. The srvmv (tip hat Paul) will give us more foundations to make the technical part of this more solid. Fully fledged plugin support that I'd be comfortable supporting would also include a defined internal API for plugins to use that we give certain guarantees to not break. I know that's a bit off, but we should get there eventually. I would like to see, before getting started on any of this, an RFC-style document / wiki page that defines what a CouchDB plugins system looks like that we agree on implementing. Cheers Jan -- > > Adam > > On Jan 20, 2011, at 8:29 AM, Benoit Chesneau wrote: > >> Actually we are using ?b2l/?l2b and some other macros to make the code >> shorter and ease our development. All these macros are in the main >> include file couch_db.hrl used everywhere in the code. >> >> Since this include will be likely used in CouchDB plugins created by >> users, I would like to have these kind of macros separated in their >> own include file. Something common in C world. The main reason is to >> not pollute namesspacing in external plugins and let them import only >> what they need, ie couchdb types/records. >> >> What do you think about it? Also, not related but maybe it could be a >> good practice to enforce the use of these macros in all the couchdb >> codebase like suggest filippe. >> >> Any thoughts ? >> >> - benoît >
