On Jan 20, 2011, at 9:26 AM, Jan Lehnardt wrote:
> > 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. +1 > > 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. +3 > > 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 >> >
