From: Mark Walters <markwalters1009@gmail.com>
To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org
Subject: Re: [PATCH 00/10] CLI output versioning
Date: Sat, 08 Dec 2012 09:29:02 +0000 [thread overview]
Message-ID: <878v98hoyp.fsf@qmul.ac.uk> (raw)
In-Reply-To: <87pq2sx86o.fsf@awakening.csail.mit.edu>
Hi
Overall this series looks good. As we discussed on irc I think i would
prefer global NOTMUCH_SCHEMA_MIN as I am a little worried about these
proliferating (eg if someone decides text output also needs versioning
etc) In addition, if we do find the distinction useful it would be easy
to add at a later date.
One tiny comment on the manpage updates: now that you mention two return
values explicitly should the other possibilities be mentioned too or are
they so obvious it is not needed?
Would it be worth having some emacs test for the error handling? (eg set
notmuch-command to something giving some stderr and an error) Inherently
these code paths won't be tested much so I think tests could be
particularly useful.
Best wishes
Mark
On Mon, 03 Dec 2012, Austin Clements <amdragon@MIT.EDU> wrote:
> (Sorry; I forgot to include a cover letter.)
>
> This series is intended to help with our long-standing output format
> versioning issue. While the JSON format is amenable to extension,
> there's still a high barrier to extensions because of the need to
> support them going forward, and an even higher barrier to modifications
> that break backwards compatibility. Versioning will make the format
> more dynamic, enabling us to easily improve and iterate on it. It will
> also address the slew of confusing bugs that people encounter when they
> use a mismatched CLI and front-end.
>
> On IRC we've talking about adding version information to the output
> format itself. This series takes a different and, I think, better
> approach: callers request a specific output format version on the
> command line. This allows notmuch to remain backwards compatible with
> older format versions when it's easy or necessary. This also doesn't
> require shoehorning a version number into the output, which would be
> awkward for both the CLI and the consumer.
>
> I called the argument --use-schema, but I'm open to other suggestions.
> --use-schema is technically accurate, but perhaps not as self-describing
> as something like --schema-version or --format-version (to parallel
> --format).
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
next prev parent reply other threads:[~2012-12-08 9:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-02 2:39 [PATCH 01/10] cli: Framework for structured output versioning Austin Clements
2012-12-02 2:39 ` [PATCH 02/10] search: Support --use-schema Austin Clements
2012-12-02 2:39 ` [PATCH 03/10] show: " Austin Clements
2012-12-02 2:39 ` [PATCH 04/10] reply: " Austin Clements
2012-12-02 2:39 ` [PATCH 05/10] test: Sanity tests for --use-schema argument Austin Clements
2012-12-02 2:39 ` [PATCH 06/10] emacs: Fix bug in resynchronizing after a JSON parse error Austin Clements
2012-12-08 8:32 ` Mark Walters
2012-12-02 2:39 ` [PATCH 07/10] emacs: Use --use-schema for search Austin Clements
2012-12-08 8:48 ` Mark Walters
2012-12-13 1:43 ` Austin Clements
2012-12-13 11:00 ` Mark Walters
2012-12-02 2:40 ` [PATCH 08/10] emacs: Factor out synchronous notmuch JSON invocations Austin Clements
2012-12-02 2:40 ` [PATCH 09/10] emacs: Improve error handling for notmuch-call-notmuch-json Austin Clements
2012-12-02 2:40 ` [PATCH 10/10] emacs: Use --use-schema for show and reply Austin Clements
2012-12-03 0:58 ` [PATCH 00/10] CLI output versioning Austin Clements
2012-12-08 9:29 ` Mark Walters [this message]
2012-12-13 1:46 ` Austin Clements
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=878v98hoyp.fsf@qmul.ac.uk \
--to=markwalters1009@gmail.com \
--cc=amdragon@MIT.EDU \
--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).