couchdb-glib, some code questions

1 view
Skip to first unread message

Mikkel Kamstrup Erlandsen

unread,
Oct 2, 2009, 2:44:17 PM10/2/09
to desktop...@googlegroups.com
Hi,

I've been wanting to have a closer look on couchdb-glib for some time
now, and decided to do so now that it has been proposed for Gnome
inclusion.

Off the bat there are a few things that I wouldn't mind at having a stab at:

* There is no gtk-doc? Is there a specific reason for this?

* Recently popular single-header include style does not seem to be
followed, I particularly like this style and coherency with Gtk and
GLib is always a plus

* The normal GObject style source layout with FooBar defined in
foo-bar.{c,h} (or foobar.{h,c}) seems to be followed a bit
inconsequently - fx. with a lot of the central types defined in
couchdb-glib.h. Said file would also normally just be a simple
aggregation of all the public headers.

Of course these items would require some source-compat breakage as
well as some refactoring - which might not be very nice since the lib
is already in use ;-) - but if I can get a conditional green light I
will have a go at it.

--
Cheers,
Mikkel

Rodrigo Moya

unread,
Oct 2, 2009, 5:53:34 PM10/2/09
to desktop...@googlegroups.com
On Fri, 2009-10-02 at 20:44 +0200, Mikkel Kamstrup Erlandsen wrote:
> Hi,
>
> I've been wanting to have a closer look on couchdb-glib for some time
> now, and decided to do so now that it has been proposed for Gnome
> inclusion.
>
> Off the bat there are a few things that I wouldn't mind at having a stab at:
>
> * There is no gtk-doc? Is there a specific reason for this?
>
no, there are not. The reason being lack of time, but I am going to work
on adding them pretty soon, so if you do so, you'll save me some work,
so go ahead please :)

> * Recently popular single-header include style does not seem to be
> followed, I particularly like this style and coherency with Gtk and
> GLib is always a plus
>
> * The normal GObject style source layout with FooBar defined in
> foo-bar.{c,h} (or foobar.{h,c}) seems to be followed a bit
> inconsequently - fx. with a lot of the central types defined in
> couchdb-glib.h. Said file would also normally just be a simple
> aggregation of all the public headers.
>

right, I guess there should be a better separation of the different
objects in different .h files. I guess we could have a
couchdb-document.h with all the CouchDBDocument-related API, and move
the top level ones (CouchDB object-related) to a couchdb-connection.h

I still would like to keep coucjdb-types.h as it is, more or less,
instead of having a .h file per type.

> Of course these items would require some source-compat breakage as
> well as some refactoring - which might not be very nice since the lib
> is already in use ;-) - but if I can get a conditional green light I
> will have a go at it.
>

well, the only API change would be the CouchDB->CouchDBConnection
renaming, which we could leave for now. The other moving around,
provided that existing apps (evolution-couchdb) can compile without any
change (it includes couchdb-glib.h, so if that makes sure to include all
that is needed, I guess it would be ok.

Or maybe we could branch it, so that you start working on all these
items as soon as you can. The only problem with branching is that we use
Launchpad for code review, which means git's master branch is imported
into lp:couchdb-glib
(https://code.edge.launchpad.net/~vcs-imports/couchdb-glib/trunk ),
which is what we use for karmic. So, I just need to find out if I can
import a branch from the git repository, and have that as the karmic
version (not sure if it's possible at all), so give me a couple of days
and I'll try to find out. If you don't hear from me, please ping me on
Monday on IRC, to make sure I don't forget :)

Mikkel Kamstrup Erlandsen

unread,
Oct 3, 2009, 4:34:37 AM10/3/09
to desktop...@googlegroups.com
2009/10/2 Rodrigo Moya <rodrig...@canonical.com>:

Right, if all consumers only include couchdb-glib.h then all is fine and dandy.

> Or maybe we could branch it, so that you start working on all these
> items as soon as you can. The only problem with branching is that we use
> Launchpad for code review, which means git's master branch is imported
> into lp:couchdb-glib
> (https://code.edge.launchpad.net/~vcs-imports/couchdb-glib/trunk ),
> which is what we use for karmic. So, I just need to find out if I can
> import a branch from the git repository, and have that as the karmic
> version (not sure if it's possible at all), so give me a couple of days
> and I'll try to find out. If you don't hear from me, please ping me on
> Monday on IRC, to make sure I don't forget :)

How about I work in a bzr branch hosted on LP? I prefer bzr anyway :-)
I'll probably just start, and then we'll figure out how to merge it...

--
Cheers,
Mikkel

Mikkel Kamstrup Erlandsen

unread,
Oct 3, 2009, 10:19:42 AM10/3/09
to desktop...@googlegroups.com
2009/10/3 Mikkel Kamstrup Erlandsen <mikkel....@gmail.com>:

FYI; I've started in lp:~kamstrup/couchdb-glib/couchdb-glib-gtkdoc. Up
until rev. 100 things are relatively sane. Then I started a BIG
refactoring in rev 101 - which still is far from complete.

--
Cheers,
Mikkel

Rodrigo Moya

unread,
Oct 4, 2009, 5:36:01 AM10/4/09
to desktop...@googlegroups.com
On Sat, 2009-10-03 at 10:34 +0200, Mikkel Kamstrup Erlandsen wrote:
> >>
> > well, the only API change would be the CouchDB->CouchDBConnection
> > renaming, which we could leave for now. The other moving around,
> > provided that existing apps (evolution-couchdb) can compile without any
> > change (it includes couchdb-glib.h, so if that makes sure to include all
> > that is needed, I guess it would be ok.
>
> Right, if all consumers only include couchdb-glib.h then all is fine and dandy.
>
well, just checked and evo-couchdb includes couchdb-document-contact.h.

> > Or maybe we could branch it, so that you start working on all these
> > items as soon as you can. The only problem with branching is that we use
> > Launchpad for code review, which means git's master branch is imported
> > into lp:couchdb-glib
> > (https://code.edge.launchpad.net/~vcs-imports/couchdb-glib/trunk ),
> > which is what we use for karmic. So, I just need to find out if I can
> > import a branch from the git repository, and have that as the karmic
> > version (not sure if it's possible at all), so give me a couple of days
> > and I'll try to find out. If you don't hear from me, please ping me on
> > Monday on IRC, to make sure I don't forget :)
>
> How about I work in a bzr branch hosted on LP? I prefer bzr anyway :-)
> I'll probably just start, and then we'll figure out how to merge it...
>

that's what I use for proposing branches for merging, so yeah, go ahead

Mikkel Kamstrup Erlandsen

unread,
Oct 5, 2009, 5:08:32 PM10/5/09
to desktop...@googlegroups.com
2009/10/4 Rodrigo Moya <rodrig...@canonical.com>:

I am mostly at a "mergeable" state now with my branch, it has been
quite an overhaul. I have not been able to run the unit tests though,
I can't connect to couch from couchdb-glib, I get an error from
send_message_and_parse() (which is called couchdb_send_message() in my
branch). Same result from trunk. It works fine with the Python
desktopcouch module though... As noted earlier the branch is here
lp:~kamstrup/couchdb-glib/couchdb-glib-gtkdoc in case anybody want a
sneak peak.

I would really like to see the unit tests running before I request a
review, but I am fairly confident I didn't break anything (famous last
words ;-)).

--
Cheers,
Mikkel

Rodrigo Moya

unread,
Oct 6, 2009, 7:53:59 AM10/6/09
to desktop...@googlegroups.com
On Mon, 2009-10-05 at 23:08 +0200, Mikkel Kamstrup Erlandsen wrote:
> >>
> >> How about I work in a bzr branch hosted on LP? I prefer bzr anyway :-)
> >> I'll probably just start, and then we'll figure out how to merge it...
> >>
> > that's what I use for proposing branches for merging, so yeah, go ahead
>
> I am mostly at a "mergeable" state now with my branch, it has been
> quite an overhaul. I have not been able to run the unit tests though,
> I can't connect to couch from couchdb-glib, I get an error from
> send_message_and_parse() (which is called couchdb_send_message() in my
> branch). Same result from trunk. It works fine with the Python
> desktopcouch module though... As noted earlier the branch is here
> lp:~kamstrup/couchdb-glib/couchdb-glib-gtkdoc in case anybody want a
> sneak peak.
>
> I would really like to see the unit tests running before I request a
> review, but I am fairly confident I didn't break anything (famous last
> words ;-)).
>

there's a bug in LP's bzr right now, which doesn't allow me to get your
branch right now, so can't run the tests. So, can you paste the output
of the test-couchdb-glib test program?

Mikkel Kamstrup Erlandsen

unread,
Oct 6, 2009, 8:27:19 AM10/6/09
to desktop...@googlegroups.com
2009/10/6 Rodrigo Moya <rodrig...@canonical.com>:

Ok, here: http://grillbar.org/files/test-couchdb-glib.out

Note that I first had to add the line below to to test-couchdb-glib.c:

couchdb_enable_oauth (couchdb, "UQBEIgilyF", "pHWotCqDbz",
"EQHVKmYlbf", "nmklBJBhab");

Then I ran it like: 'tests/test-couchdb-glib http://127.0.0.1:5000 >
test-couchdb-glib.out 2>&1' to make sure I also capture stderr.

Oddly enough, after running the tests a few times it started aborting
with the message you will see at the bottom of my linked log. I swear
to god that it passed the first 3-4 times I ran it. It looks like the
couchdb server returns a code 500 - but I haven't checked it yet.

--
Cheers,
Mikkel

Rodrigo Moya

unread,
Oct 6, 2009, 11:28:29 AM10/6/09
to desktop...@googlegroups.com
yes, seems couchdb is failing, see ~/.cache/desktop-couch/ log files, to
see if you find any useful information

BTW, see my last comment to your branch merge proposal. We should be
landing your branch to GIT master very soon

Reply all
Reply to author
Forward
0 new messages