d4/37cd22a86fe29623406a5d6b32ff88e464869d

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 4A75D431FD0\r
   6         for <notmuch@notmuchmail.org>; Wed, 22 Jun 2011 06:58:23 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id Kmv0zYxfSIdo for <notmuch@notmuchmail.org>;\r
  16         Wed, 22 Jun 2011 06:58:22 -0700 (PDT)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
  18         by olra.theworths.org (Postfix) with ESMTP id B27DE431FB6\r
  19         for <notmuch@notmuchmail.org>; Wed, 22 Jun 2011 06:58:22 -0700 (PDT)\r
  20 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  21         by arlo.cworth.org (Postfix) with ESMTP id C32E729A041;\r
  22         Wed, 22 Jun 2011 06:58:21 -0700 (PDT)\r
  23 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  24         id BBC4D254157; Wed, 22 Jun 2011 06:58:21 -0700 (PDT)\r
  25 From: Carl Worth <cworth@cworth.org>\r
  26 To: Sebastian Spaeth <Sebastian@SSpaeth.de>,\r
  27         Notmuch developer list <notmuch@notmuchmail.org>\r
  28 Subject: Re: Python updates\r
  29 In-Reply-To: <87d3i673qy.fsf@SSpaeth.de>\r
  30 References: <87k4cmavoc.fsf@SSpaeth.de> <8739j9yj1s.fsf@SSpaeth.de>\r
  31         <87wrgeeu3p.fsf@yoom.home.cworth.org> <87d3i673qy.fsf@SSpaeth.de>\r
  32 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1\r
  33         (i486-pc-linux-gnu)\r
  34 Date: Wed, 22 Jun 2011 06:58:16 -0700\r
  35 Message-ID: <87mxhaeznr.fsf@yoom.home.cworth.org>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: multipart/signed; boundary="=-=-=";\r
  38         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43         <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Wed, 22 Jun 2011 13:58:23 -0000\r
  52 \r
  53 --=-=-=\r
  54 Content-Transfer-Encoding: quoted-printable\r
  55 \r
  56 On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth <Sebastian@SSpaeth.de>=\r
  57  wrote:\r
  58 > I see your point. I was approached with this by someone very\r
  59 > confused that tagging via notmuch binary would automatically move mails\r
  60 > between cur/new folders while tagging via python would do nothing of\r
  61 > this sort.\r
  62 \r
  63 That's also a good point.\r
  64 \r
  65 But the same confusion can happen to someone using "notmuch tag" and\r
  66 then switching to using notmuch_message_add_tag at the C library\r
  67 interface.\r
  68 \r
  69 That's what I meant when I said that if there's an inconsistency here,\r
  70 then we should fix it at the C library interface, and not just in a\r
  71 language-specific wrapper.\r
  72 \r
  73 > See above, people don't consider using the libnotmuch API, they "tag" a\r
  74 > message via python and it behaves differently than "tag" a message via\r
  75 > notmuch binary....\r
  76 > So we'll have some level of inconsistency in any case. :)\r
  77 \r
  78 Let's figure out one right answer for the library interface, (regardless\r
  79 of language) and implement that.\r
  80 \r
  81 > Would you be happy to have maildir syncing disabled by default and users\r
  82 > can enable it via a parameter?\r
  83 \r
  84 I'd be happy to hear a proposal to add a parameter to the library\r
  85 interface for maildir syncing, (and I wouldn't even be opposed to having\r
  86 it enabled by default).\r
  87 \r
  88 The only thing I care about strongly here is that we have a single\r
  89 library interface. I don't want one interface in C, a different\r
  90 interface in python, (and different interfaces in go, ruby, etc.).\r
  91 \r
  92 Sometimes a language will provide some convenient builtin handling for\r
  93 something that's awkward at the notmuch C interface, (such as a native\r
  94 interface for iterators). And I definitely don't mind a language binding\r
  95 using something like that as opposed to manually binding every\r
  96 iteration-supporting function that we have in the notmuch library.\r
  97 \r
  98 But I don't want to see semantic changes to the interface that don't\r
  99 have anything to do with the language itself.\r
 100 \r
 101 > I do see why you want to achieve consistency with the API.\r
 102 \r
 103 Thanks.\r
 104 \r
 105 > On the other hand are the python API somewhat more highlevel than the\r
 106 > low-level API calls, and we provide a few convenience functions that\r
 107 > are not available in the API at all.\r
 108 \r
 109 That's not the stance I'd like to see.\r
 110 \r
 111 If you want convenience in the python interface that doesn't exist in\r
 112 the C interface, then let's start by fixing the C interface.\r
 113 \r
 114 If there's convenience you want in the python interface that shouldn't\r
 115 exist in the C interface, then I would propose that that functionality\r
 116 should be in a separate python layer (above the binding) with its own\r
 117 name.\r
 118 \r
 119 What do you think?\r
 120 \r
 121 =2DCarl\r
 122 \r
 123 =2D-=20\r
 124 carl.d.worth@intel.com\r
 125 \r
 126 --=-=-=\r
 127 Content-Type: application/pgp-signature\r
 128 \r
 129 -----BEGIN PGP SIGNATURE-----\r
 130 Version: GnuPG v1.4.11 (GNU/Linux)\r
 131 \r
 132 iEYEARECAAYFAk4B9PgACgkQ6JDdNq8qSWgUxwCffRnrH4mg9y4dmBmk5j85hvIg\r
 133 oGwAn2GkMSPqp6Fd/ChDCP8hgprNEY5T\r
 134 =KFng\r
 135 -----END PGP SIGNATURE-----\r
 136 --=-=-=--\r