From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id EBA51431FC0 for ; Sat, 24 Nov 2012 20:57:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYjC4unLnkr0 for ; Sat, 24 Nov 2012 20:57:19 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by olra.theworths.org (Postfix) with ESMTP id 54DDD431FAF for ; Sat, 24 Nov 2012 20:57:19 -0800 (PST) X-AuditID: 12074424-b7fce6d000000925-36-50b1a52d07e5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 70.DA.02341.D25A1B05; Sat, 24 Nov 2012 23:57:17 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id qAP4vGEq023558; Sat, 24 Nov 2012 23:57:16 -0500 Received: from drake.dyndns.org (209-6-116-242.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com [209.6.116.242]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qAP4vDVU000080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 24 Nov 2012 23:57:16 -0500 (EST) Received: from amthrax by drake.dyndns.org with local (Exim 4.77) (envelope-from ) id 1TcUHJ-0003Zj-QV; Sat, 24 Nov 2012 23:57:13 -0500 From: Austin Clements To: notmuch@notmuchmail.org Subject: [PATCH 0/6] API for iterating over all messages in a thread Date: Sat, 24 Nov 2012 23:57:01 -0500 Message-Id: <1353819427-13182-1-git-send-email-amdragon@mit.edu> X-Mailer: git-send-email 1.7.10.4 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUixG6noqu7dGOAwZVGQYvVc3ksrt+cyezA 5LFz1l12j2erbjEHMEVx2aSk5mSWpRbp2yVwZTxZYVgwiati58NlzA2M8zi6GDk5JARMJNrv bWKGsMUkLtxbz9bFyMUhJLCPUWLOptvMEM4GRonHtz6AVQkJPGKSmLumCiIxl1Hi8PStYAk2 AQ2JbfuXM4LYIgLSEjvvzmYFsZkFZCV+nP8DZgsLuEj03zzKDmKzCKhKdDTNBOvlFXCQ6Jrb ywRxhqJE97MJbBMYeRcwMqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdfLzSzRS00p3cQIDgsX lR2MzYeUDjEKcDAq8fDeSNwYIMSaWFZcmXuIUZKDSUmUN3MRUIgvKT+lMiOxOCO+qDQntfgQ owQHs5IIr7UqUI43JbGyKrUoHyYlzcGiJM57PeWmv5BAemJJanZqakFqEUxWhoNDSYJXZAlQ o2BRanpqRVpmTglCmomDE2Q4D9BwUZAa3uKCxNzizHSI/ClGRSlxXnOQhABIIqM0D64XFrev GMWBXhHmdQCp4gHGPFz3K6DBTECDn85eBzK4JBEhJdXAqPbxYOm+Uz/ZPwv8tGieMnevQ4Ks bGPVJv5j9z4w5RxnrXyza+eTJInbQmzXNihMeSNiWB4ud8dUcd8UM0eL5y4/9F7dvLz7kIuA 9bzHqxqzpsxeN6PlGmPJnEPn4u/wCQf8OiGoPPF7jvIRtq71Uu/DeoUry2bV79swTefH2oCZ dl0HdrsHFimxFGckGmoxFxUnAgAsvMeotgIAAA== X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 04:57:20 -0000 This series adds a library API for iterating over all messages in a thread in sorted order. This is easy for the library to provide and difficult to obtain from the current API. Plus, if you don't count the code added to the bindings, this series is actually a net decrease of 4 lines of code because of simplifications it enables. Do we want the API to do more? Currently it's very minimal, but I can imagine two ways it could be generalized. It could take an argument to indicate which message list to return, which could be all messages, matched messages, top-level messages, or maybe even unmatched messages (possibly all in terms of message flags). It could also take an argument indicating the desired sort order. Currently, the caller can use existing message flag APIs to distinguish matched and unmatched messages and there's a separate function for the top-level messages. However, if the API could do all of these things, it would subsume various other API functions, such as notmuch_thread_get_*_date. Also, is this the right name for the new API? In particular, if we do later want to add a function that returns, say, the list of matched messages, we'll have a convention collision with notmuch_thread_get_matched_messages, which returns only a count.