You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2011/01/20 14:29:41 UTC
code style
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
Re: code style
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Jan 20, 2011 at 8:58 AM, Robert Newson <ro...@gmail.com> wrote:
> +1 on using ?l2b (and other macros) in all src/couchdb code. Any
> lingering list_to_binary calls should be switched to the macro.
>
> I think it's too early to split out the header file to allow use by
> plugin authors. I'm in a minority, I think, by saying that without
> some extra work, we are not ready to claim we support plugins.
>
> I'd like to see, at minimum, a versioning scheme to declare
> compatibility between couchdb and plugins (like browsers do, for
> example). Beyond that, a statement on what parts of the interior of
> couchdb are considered stable enough for plugin authors to depend on.
>
> B.
>
I think you are spot on and totally forgetting how Erlang works.
I agree completely that we shouldn't *say* that we support plugins as
we start adding the facilities to *allow* for plugins.
Also, given that Erlang is a hugely flat namespace that allows anyone
to call anything with impunity, it doesn't really matter what we *say*
we consider stable so much as actually keeping it stable. For the next
bit and awhile, the only people writing plugins are probably going to
be already fairly familiar with Erlang and the internals and I think
we should encourage them to do so, so that we can get feedback on what
parts of the API *need* to be stable.
Also, I just had a bit of a freak out there thinking I'd forgotten to
update the app file but then remembered that every copy of Erlang is
tied to its version, so that's already taken care.
Re: code style
Posted by Robert Newson <ro...@gmail.com>.
+1 on using ?l2b (and other macros) in all src/couchdb code. Any
lingering list_to_binary calls should be switched to the macro.
I think it's too early to split out the header file to allow use by
plugin authors. I'm in a minority, I think, by saying that without
some extra work, we are not ready to claim we support plugins.
I'd like to see, at minimum, a versioning scheme to declare
compatibility between couchdb and plugins (like browsers do, for
example). Beyond that, a statement on what parts of the interior of
couchdb are considered stable enough for plugin authors to depend on.
B.
On Thu, Jan 20, 2011 at 1:36 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Jan 20, 2011 at 2:29 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> codebase like suggest filippe.
>>
> s/filippe/filipe/ *kh*
>
Re: code style
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jan 20, 2011 at 2:29 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> codebase like suggest filippe.
>
s/filippe/filipe/ *kh*
Re: Erlang API (was Re: code style)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Jan 24, 2011 at 4:06 PM, Adam Kocoloski <ko...@apache.org> wrote:
> On Jan 23, 2011, at 7:40 AM, Filipe David Manana wrote:
>
>> On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>
>>> Imo the thing we could have in view, except this plugin "support", is
>>> a simple api to call any part of couchdb we need. Something as simple
>>> as the HTTP api but for erlang.
>>>
>>> I'm thinking to have a couchbeam pure erlang api for example just for
>>> that. It would also help us to make new HTTP layer using webmachine
>>> for example or anything. fabric an hovercraft are also good
>>> inspiration. I'm pretty ready to do such thing. Does it worth a thread
>>> to discuss about it?
>>
>> You already have that with the new replicator. It brings a module
>> named "couch_api_wrap.erl". For now, it only has functions necessary
>> for the replicator to operate both with local and remote databases.
>> Nevertheless, it already covers a significant subset of the CouchDB API
>
> Yes, I think it's good to have a separate discussion on this one, but I'll go ahead and toss my thoughts in here as well. One of the things I quite like about fabric.erl as opposed to couch_api_wrap.erl is that it minimizes the use of records in the interface, e.g. it has converters to turn client-supplied proplists into internal #changes_args and #view_query_args. I also like that it accepts iodata() for most strings instead of requiring the client to convert to binaries. It saves some typing when interacting with BigCouch from the shell.
>
+1 That's indeed really convenient as a client level.
> I think one big question for an Erlang API is whether it should require the client to manually open and close the DB. Fabric does not impose this requirement, primarily because it doesn't make much sense in a BigCouch cluster. There are certainly advantages to having a DB handle open, but I think many of those can be nullified by making it really cheap to open a DB. My preference would be to make it optional, i.e. functions like update_docs would have a clause that accepts a DbName (and a user context in the options) in addition to one that accepts a #db.
At least I don't think we should test if a db exists or not when we
open a db like in couch_api_wrap, rather we should make it lazy and
crash only when we call a function using the db. So we minimize call.
I'm not sure about the impact of opening/closing a db right now but I
guess that if we monitor activity of the db process it should we the
case we let a db open?
- benoît
Erlang API (was Re: code style)
Posted by Adam Kocoloski <ko...@apache.org>.
On Jan 23, 2011, at 7:40 AM, Filipe David Manana wrote:
> On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>> Imo the thing we could have in view, except this plugin "support", is
>> a simple api to call any part of couchdb we need. Something as simple
>> as the HTTP api but for erlang.
>>
>> I'm thinking to have a couchbeam pure erlang api for example just for
>> that. It would also help us to make new HTTP layer using webmachine
>> for example or anything. fabric an hovercraft are also good
>> inspiration. I'm pretty ready to do such thing. Does it worth a thread
>> to discuss about it?
>
> You already have that with the new replicator. It brings a module
> named "couch_api_wrap.erl". For now, it only has functions necessary
> for the replicator to operate both with local and remote databases.
> Nevertheless, it already covers a significant subset of the CouchDB API
Yes, I think it's good to have a separate discussion on this one, but I'll go ahead and toss my thoughts in here as well. One of the things I quite like about fabric.erl as opposed to couch_api_wrap.erl is that it minimizes the use of records in the interface, e.g. it has converters to turn client-supplied proplists into internal #changes_args and #view_query_args. I also like that it accepts iodata() for most strings instead of requiring the client to convert to binaries. It saves some typing when interacting with BigCouch from the shell.
I think one big question for an Erlang API is whether it should require the client to manually open and close the DB. Fabric does not impose this requirement, primarily because it doesn't make much sense in a BigCouch cluster. There are certainly advantages to having a DB handle open, but I think many of those can be nullified by making it really cheap to open a DB. My preference would be to make it optional, i.e. functions like update_docs would have a clause that accepts a DbName (and a user context in the options) in addition to one that accepts a #db.
>
>>
>> - benoît
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
Re: code style
Posted by Filipe David Manana <fd...@apache.org>.
On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
> Imo the thing we could have in view, except this plugin "support", is
> a simple api to call any part of couchdb we need. Something as simple
> as the HTTP api but for erlang.
>
> I'm thinking to have a couchbeam pure erlang api for example just for
> that. It would also help us to make new HTTP layer using webmachine
> for example or anything. fabric an hovercraft are also good
> inspiration. I'm pretty ready to do such thing. Does it worth a thread
> to discuss about it?
You already have that with the new replicator. It brings a module
named "couch_api_wrap.erl". For now, it only has functions necessary
for the replicator to operate both with local and remote databases.
Nevertheless, it already covers a significant subset of the CouchDB API
>
> - benoît
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: code style
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jan 20, 2011 at 4:16 PM, Paul Davis <pa...@gmail.com> wrote:
>> 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.
>>
>
> If this were any/most other languages I would totally agree. Except
> Erlang is kinda laissez-faire when it comes to calling bits of code.
>
> Regardless of what the "plugin" system ends up looking like, it'll
> basically be the same API that's used all over couchdb internals.
> It'll be self-automatically stable once we make it not suck.
>
> *After* there's a system in place that allows plugins to exist without
> a carnal knowledge of the code base I think it would be good to
> explicitly formalize what we support as a plugin but until then we
> just don't make any claim of supporting anything as we start adding
> and organizing in preparation.
>
Imo the thing we could have in view, except this plugin "support", is
a simple api to call any part of couchdb we need. Something as simple
as the HTTP api but for erlang.
I'm thinking to have a couchbeam pure erlang api for example just for
that. It would also help us to make new HTTP layer using webmachine
for example or anything. fabric an hovercraft are also good
inspiration. I'm pretty ready to do such thing. Does it worth a thread
to discuss about it?
- benoît
Re: code style
Posted by Paul Davis <pa...@gmail.com>.
> 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.
>
If this were any/most other languages I would totally agree. Except
Erlang is kinda laissez-faire when it comes to calling bits of code.
Regardless of what the "plugin" system ends up looking like, it'll
basically be the same API that's used all over couchdb internals.
It'll be self-automatically stable once we make it not suck.
*After* there's a system in place that allows plugins to exist without
a carnal knowledge of the code base I think it would be good to
explicitly formalize what we support as a plugin but until then we
just don't make any claim of supporting anything as we start adding
and organizing in preparation.
Re: code style
Posted by Robert Dionne <di...@dionne-associates.com>.
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
>>
>
Re: code style
Posted by Jan Lehnardt <ja...@apache.org>.
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
>
Re: code style
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jan 20, 2011 at 2:57 PM, Adam Kocoloski <ko...@apache.org> 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,
>
> Adam
>
+ 1 for such changes. While we are here we do the same for current
includes (waiting a better world) in ibrowse version etc and adding
include to erlopts when we build ?
- benoit
Re: code style
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Jan 20, 2011 at 8:59 AM, Robert Newson <ro...@gmail.com> wrote:
> +1 on moving it to include/ though.
>
> The deeper in I get, the less OTP like couchdb looks to me... :)
>
Where've you been? Britain?
> B.
>
> On Thu, Jan 20, 2011 at 1:57 PM, Adam Kocoloski <ko...@apache.org> 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,
>>
>> 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
>>
>>
>
Re: code style
Posted by Robert Newson <ro...@gmail.com>.
+1 on moving it to include/ though.
The deeper in I get, the less OTP like couchdb looks to me... :)
B.
On Thu, Jan 20, 2011 at 1:57 PM, Adam Kocoloski <ko...@apache.org> 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,
>
> 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
>
>
Re: code style
Posted by Filipe David Manana <fd...@apache.org>.
Btw, related, the new replicator adds two new header files:
couch_replicator.hrl and couch_api_wrap.hrl. This is to avoid having
every single record in couch_db.hrl.
On Thu, Jan 20, 2011 at 1:57 PM, Adam Kocoloski <ko...@apache.org> 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,
>
> 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
>
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: code style
Posted by Adam Kocoloski <ko...@apache.org>.
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,
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