1 Return-Path: <bremner@unb.ca>
\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 4B633431FB6
\r
6 for <notmuch@notmuchmail.org>; Wed, 4 Apr 2012 03:55:39 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 BYHRANrjliv6 for <notmuch@notmuchmail.org>;
\r
16 Wed, 4 Apr 2012 03:55:37 -0700 (PDT)
\r
17 Received: from tesseract.cs.unb.ca (tesseract.cs.unb.ca [131.202.240.238])
\r
18 (using TLSv1 with cipher AES256-SHA (256/256 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id C4BD1431FAE
\r
21 for <notmuch@notmuchmail.org>; Wed, 4 Apr 2012 03:55:37 -0700 (PDT)
\r
22 Received: from fctnnbsc30w-156034089108.dhcp-dynamic.fibreop.nb.bellaliant.net
\r
23 ([156.34.89.108] helo=zancas.localnet)
\r
24 by tesseract.cs.unb.ca with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
\r
25 (Exim 4.72) (envelope-from <bremner@unb.ca>)
\r
26 id 1SFNsA-0008HH-5J; Wed, 04 Apr 2012 07:55:30 -0300
\r
27 Received: from bremner by zancas.localnet with local (Exim 4.77)
\r
28 (envelope-from <bremner@unb.ca>)
\r
29 id 1SFNs4-0004qY-Ms; Wed, 04 Apr 2012 07:55:24 -0300
\r
30 From: David Bremner <bremner@unb.ca>
\r
31 To: Jameson Graef Rollins <jrollins@finestructure.net>,
\r
32 Jani Nikula <jani@nikula.org>
\r
33 Subject: Re: [PATCH 6/8] cli: add support for batch tagging operations to
\r
35 In-Reply-To: <87aa2s2aow.fsf@servo.finestructure.net>
\r
36 References: <cover.1333231401.git.jani@nikula.org>
\r
37 <f360a40bed50208d146aee8b06946b1b8315e818.1333231401.git.jani@nikula.org>
\r
38 <87ty123tpc.fsf@servo.finestructure.net>
\r
39 <87aa2tc22z.fsf@zancas.localnet>
\r
40 <87iphh50hz.fsf@servo.finestructure.net>
\r
41 <CAB+hUn_J9oOmbWaQ+_2yGG6i6ecDXbfJWYbpaYx_kbSnAH+EcA@mail.gmail.com>
\r
42 <87fwcl4yr8.fsf@servo.finestructure.net>
\r
43 <CAB+hUn-5yB15na2kFMZOjOEujKQTWHiefvgQYsT4Zi3UOzKwQw@mail.gmail.com>
\r
44 <87d37p4xor.fsf@servo.finestructure.net>
\r
45 <87pqbpxm2c.fsf@nikula.org>
\r
46 <87wr5w2zv5.fsf@servo.finestructure.net>
\r
47 <87bon82qok.fsf@zancas.localnet>
\r
48 <87aa2s2aow.fsf@servo.finestructure.net>User-Agent:
\r
49 Notmuch/0.12+70~g46e73fe (http://notmuchmail.org) Emacs/23.3.1
\r
50 (x86_64-pc-linux-gnu)
\r
51 Date: Wed, 04 Apr 2012 07:55:24 -0300
\r
52 Message-ID: <878vib3gwz.fsf@zancas.localnet>
\r
54 Content-Type: text/plain; charset=us-ascii
\r
56 Cc: Notmuch Mail <notmuch@notmuchmail.org>
\r
57 X-BeenThere: notmuch@notmuchmail.org
\r
58 X-Mailman-Version: 2.1.13
\r
60 List-Id: "Use and development of the notmuch mail system."
\r
61 <notmuch.notmuchmail.org>
\r
62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
63 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
65 List-Post: <mailto:notmuch@notmuchmail.org>
\r
66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
68 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
69 X-List-Received-Date: Wed, 04 Apr 2012 10:55:39 -0000
\r
71 Jameson Graef Rollins <jrollins@finestructure.net> writes:
\r
73 > With that in mind, I think I stand by my suggestion that the form should
\r
74 > match exactly the notmuch subcommand format. Even considering the
\r
75 > technical issues that Jani brought up, I still think it makes the most
\r
76 > sense to imagine generic batch processing handled by the top level
\r
77 > binary. And in that case the most logical format for the input is
\r
78 > probably just that of the CLI arguments.
\r
80 One thing that worries me about this (and to be honest it worries me a
\r
81 bit about the single character command tag) is the potential increase in
\r
82 size of a dump file, if we use exactly a list of commands as a dump
\r
83 format. The SQL/XML-like argument that it will all compress well is
\r
84 true; nontheless for applications involving version control, it does
\r
85 seem useful to have an uncompressed version around.
\r
87 A very rough estimate suggests for my about 250k messages, appending
\r
88 "tag " to the front of each line bloats a dump file by about 5%. Maybe
\r
89 that is not worth worrying about. I'd be curious to see how 4 * #lines /
\r
90 (total dump size) works out for other people. I thought that the bloat
\r
91 from having + in front of every tag would be larger, but it seems that
\r
92 my messages average something like one tag per message (many messages
\r
93 with no tags). I'm not sure how universal that is.
\r
95 We could also give up on marking the command on each line, and insert
\r
96 some kind of simple header at the top. This idea came up in the context
\r
97 of restore formats before.
\r
99 > Just out of curiosity and for the sake of argument, if we were going to
\r
100 > design a server/batch processor from the ground up would it make sense
\r
101 > to use a format like this, or would we better off opting for some other
\r
102 > more established protocol?
\r
104 I guess it depends how much work it is to support the established
\r
105 protocol, and how good the fit is with notmuch. Are there candidates
\r
108 As far as implementation effort, as a totally unscientific experiment, I
\r
109 grabbed Net::IMAP::Server from CPAN, it is almost 7000 lines of
\r
110 perl. I'm not suggesting we use Perl ;), but I doubt C is
\r
111 shorter. Hopefully we wouldn't write such a library from scratch. A
\r
112 quick search did not lead me to "the canonical imap server library",
\r
113 unless that is the UW one, which I have bad, if non-specific memories
\r
116 I think we'd need to use a fair number of extensions to basic IMAP. What
\r
117 might work well is the GMail extensions to IMAP. I have no idea about
\r
118 the difficulty of implementing those; I suspect there are not solid C
\r
119 libraries supporting them.
\r
projects / notmuch-archives.git / blob