From: David Bremner <bremner@unb.ca>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
Jani Nikula <jani@nikula.org>
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"
Date: Wed, 04 Apr 2012 07:55:24 -0300 [thread overview]
Message-ID: <878vib3gwz.fsf@zancas.localnet> (raw)
In-Reply-To: <87aa2s2aow.fsf@servo.finestructure.net>
Jameson Graef Rollins <jrollins@finestructure.net> writes:
> With that in mind, I think I stand by my suggestion that the form should
> match exactly the notmuch subcommand format. Even considering the
> technical issues that Jani brought up, I still think it makes the most
> sense to imagine generic batch processing handled by the top level
> binary. And in that case the most logical format for the input is
> probably just that of the CLI arguments.
One thing that worries me about this (and to be honest it worries me a
bit about the single character command tag) is the potential increase in
size of a dump file, if we use exactly a list of commands as a dump
format. The SQL/XML-like argument that it will all compress well is
true; nontheless for applications involving version control, it does
seem useful to have an uncompressed version around.
A very rough estimate suggests for my about 250k messages, appending
"tag " to the front of each line bloats a dump file by about 5%. Maybe
that is not worth worrying about. I'd be curious to see how 4 * #lines /
(total dump size) works out for other people. I thought that the bloat
from having + in front of every tag would be larger, but it seems that
my messages average something like one tag per message (many messages
with no tags). I'm not sure how universal that is.
We could also give up on marking the command on each line, and insert
some kind of simple header at the top. This idea came up in the context
of restore formats before.
> Just out of curiosity and for the sake of argument, if we were going to
> design a server/batch processor from the ground up would it make sense
> to use a format like this, or would we better off opting for some other
> more established protocol?
I guess it depends how much work it is to support the established
protocol, and how good the fit is with notmuch. Are there candidates
other than IMAP?
As far as implementation effort, as a totally unscientific experiment, I
grabbed Net::IMAP::Server from CPAN, it is almost 7000 lines of
perl. I'm not suggesting we use Perl ;), but I doubt C is
shorter. Hopefully we wouldn't write such a library from scratch. A
quick search did not lead me to "the canonical imap server library",
unless that is the UW one, which I have bad, if non-specific memories
about.
I think we'd need to use a fair number of extensions to basic IMAP. What
might work well is the GMail extensions to IMAP. I have no idea about
the difficulty of implementing those; I suspect there are not solid C
libraries supporting them.
d
next prev parent reply other threads:[~2012-04-04 10:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 22:17 [PATCH 0/8] batch tagging support: "notmuch tag --stdin" Jani Nikula
2012-03-31 22:17 ` [PATCH 1/8] hex-escape: (en|de)code strings to/from restricted character set Jani Nikula
2012-03-31 22:17 ` [PATCH 2/8] hex-escape: be more strict about the format while decoding Jani Nikula
2012-04-05 11:33 ` David Bremner
2012-04-05 11:49 ` Jani Nikula
2012-04-05 11:59 ` David Bremner
2012-03-31 22:17 ` [PATCH 3/8] hex-escape: add function to decode escaped string in-place Jani Nikula
2012-04-05 11:56 ` David Bremner
2012-04-05 12:00 ` Jani Nikula
2012-03-31 22:17 ` [PATCH 4/8] test/hex-xcode: new test binary Jani Nikula
2012-03-31 22:17 ` [PATCH 5/8] test/hex-escaping: new test for hex escaping routines Jani Nikula
2012-03-31 22:17 ` [PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag" Jani Nikula
2012-04-02 17:51 ` Jameson Graef Rollins
2012-04-02 19:46 ` Jani Nikula
2012-04-02 17:54 ` Jameson Graef Rollins
2012-04-02 20:26 ` David Bremner
2012-04-02 20:42 ` Jameson Graef Rollins
2012-04-02 21:07 ` Jani Nikula
2012-04-02 21:20 ` Jameson Graef Rollins
2012-04-02 21:31 ` Jani Nikula
2012-04-02 21:43 ` Jameson Graef Rollins
2012-04-03 8:21 ` Jani Nikula
2012-04-03 22:51 ` Jameson Graef Rollins
2012-04-04 2:09 ` David Bremner
2012-04-04 7:55 ` Jameson Graef Rollins
2012-04-04 10:55 ` David Bremner [this message]
2012-03-31 22:17 ` [PATCH 7/8] test: add test for notmuch tag --stdin option Jani Nikula
2012-03-31 22:17 ` [PATCH 8/8] man: document " Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878vib3gwz.fsf@zancas.localnet \
--to=bremner@unb.ca \
--cc=jani@nikula.org \
--cc=jrollins@finestructure.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).