From: Carl Worth <cworth@cworth.org>
To: Sebastian Spaeth <Sebastian@SSpaeth.de>,
	Notmuch developer list <notmuch@notmuchmail.org>
Subject: Re: Python updates
In-Reply-To: <87d3i673qy.fsf@SSpaeth.de>
References: <87k4cmavoc.fsf@SSpaeth.de> <8739j9yj1s.fsf@SSpaeth.de>
	<87wrgeeu3p.fsf@yoom.home.cworth.org> <87d3i673qy.fsf@SSpaeth.de>
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
	(i486-pc-linux-gnu)
Date: Wed, 22 Jun 2011 06:58:16 -0700
Message-ID: <87mxhaeznr.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

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?

=2DCarl

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4B9PgACgkQ6JDdNq8qSWgUxwCffRnrH4mg9y4dmBmk5j85hvIg
oGwAn2GkMSPqp6Fd/ChDCP8hgprNEY5T
=KFng
-----END PGP SIGNATURE-----
--=-=-=--