On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth <sebast...@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.wo...@intel.com
pgpwEMfEAIRQE.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch