On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth <Sebastian@SSpaeth.de> wrote:
> I see your point. I was approached with this by someone very
> confused that tagging via notmuch binary would automatically move mails
> between cur/new folders while tagging via python would do nothing of
> this sort.

That's also a good point.

But the same confusion can happen to someone using "notmuch tag" and
then switching to using notmuch_message_add_tag at the C library
interface.

That's what I meant when I said that if there's an inconsistency here,
then we should fix it at the C library interface, and not just in a
language-specific wrapper.

> See above, people don't consider using the libnotmuch API, they "tag" a
> message via python and it behaves differently than "tag" a message via
> notmuch binary....
> So we'll have some level of inconsistency in any case. :)

Let's figure out one right answer for the library interface, (regardless
of language) and implement that.

> Would you be happy to have maildir syncing disabled by default and users
> can enable it via a parameter?

I'd be happy to hear a proposal to add a parameter to the library
interface for maildir syncing, (and I wouldn't even be opposed to having
it enabled by default).

The only thing I care about strongly here is that we have a single
library interface. I don't want one interface in C, a different
interface in python, (and different interfaces in go, ruby, etc.).

Sometimes a language will provide some convenient builtin handling for
something that's awkward at the notmuch C interface, (such as a native
interface for iterators). And I definitely don't mind a language binding
using something like that as opposed to manually binding every
iteration-supporting function that we have in the notmuch library.

But I don't want to see semantic changes to the interface that don't
have anything to do with the language itself.

> I do see why you want to achieve consistency with the API.

Thanks.

> On the other hand are the python API somewhat more highlevel than the
> low-level API calls, and we provide a few convenience functions that
> are not available in the API at all.

That's not the stance I'd like to see.

If you want convenience in the python interface that doesn't exist in
the C interface, then let's start by fixing the C interface.

If there's convenience you want in the python interface that shouldn't
exist in the C interface, then I would propose that that functionality
should be in a separate python layer (above the binding) with its own
name.

What do you think?

-Carl

-- 
carl.d.worth@intel.com