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 E5E4A431FBD for ; Sun, 15 Jan 2012 12:35:21 -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 MnHXcLjDPcow for ; Sun, 15 Jan 2012 12:35:20 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by olra.theworths.org (Postfix) with ESMTP id 5ECCA431FAE for ; Sun, 15 Jan 2012 12:35:20 -0800 (PST) X-AuditID: 1209190d-b7fbf6d0000008ba-de-4f133887fee9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.4B.02234.888331F4; Sun, 15 Jan 2012 15:35:20 -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 q0FKZIhr025833; Sun, 15 Jan 2012 15:35:19 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0FKZHO2001827 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 15 Jan 2012 15:35:18 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RmWnH-00045O-C9; Sun, 15 Jan 2012 15:35:11 -0500 Date: Sun, 15 Jan 2012 15:35:11 -0500 From: Austin Clements To: David Bremner Subject: Re: [PATCH v3 04/10] notmuch-dump: add --format=(notmuch|sup) Message-ID: <20120115203511.GB9385@mit.edu> References: <874nwxbkhr.fsf@zancas.localnet> <1326591624-15493-1-git-send-email-david@tethera.net> <1326591624-15493-5-git-send-email-david@tethera.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326591624-15493-5-git-send-email-david@tethera.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0e2wEPY32NTPbLFx2U9mixut3YwW 12/OZHZg9vjVNpfZ49mqW8weWw69Zw5gjuKySUnNySxLLdK3S+DK+PWkm73gMUdFx/JDTA2M E9i7GDk4JARMJLa3iXcxcgKZYhIX7q1n62Lk4hAS2McocXxSDzOEs4FRYtrOJawQzkkmib/X zrJAOEsYJV51H2QDGcUioCqx5n0WyCg2AQ2JbfuXM4LYIkDhq9sms4HYzAL2EotmTwLbLCzg JnHsXyBImFdAW2JG/0R2iJFzGCW6H21lhkgISpyc+YQFoldL4sa/l0wgvcwC0hLL/3GAhDkF nCRuP94FtkpUQEViysltbBMYhWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealF ukZ6uZkleqkppZsYQYHOKcm7g/HdQaVDjAIcjEo8vMKqQv5CrIllxZW5hxglOZiURHmLtIX9 hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwtukD5XhTEiurUovyYVLSHCxK4ryqWu/8hATSE0tS s1NTC1KLYLIyHBxKErz3zIEaBYtS01Mr0jJzShDSTBycIMN5gIYfBqnhLS5IzC3OTIfIn2JU lBLnfQmSEABJZJTmwfXCEtErRnGgV4R5r4FU8QCTGFz3K6DBTECDc1qFQAaXJCKkpBoYz055 +0q0sMBo4rF7enlxjRUpzvUvwrsFb73vdzTd7XXhQOre/Am9z4QOaETt1VzRIZrQqNNadXHJ wovLHzF0BZrMf3J+bsx/x0UTV6wr3PulbTrPlPBcaeFX1nqHTQw33AxZsYPXtENUflLb9QXs XNPKy39sWJ5zx3gz69Vzr2L7t8n3ZRjEKrEUZyQaajEXFScCAOSix6cfAwAA Cc: notmuch@notmuchmail.org, David Bremner 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, 15 Jan 2012 20:35:22 -0000 Quoth David Bremner on Jan 14 at 9:40 pm: > From: David Bremner > > sup is the old format, and remains the default. > > Each line of the notmuch format is "msg_id tag tag...tag" where each > space seperated token is 'hex-encoded' to remove troubling characters. > In particular this format won't have the same problem with e.g. spaces > in message-ids or tags; they will be round-trip-able. We definitely need a round-trip-able dump format. Did you consider using JSON to allow for future flexibility (e.g., expansion of what we store in the database) and so we don't have to invent our own encodings? A JSON format wouldn't necessarily be a reason *not* to also have this format, especially considering how shell-script-friendly this is (versus how shell-script-unfriendly JSON is), I'm just curious what trade-offs you're considering. You might want to call this format something more self-descriptive like "text" or "hextext" or something in case we do want to expand in the future. "sup" is probably fine for the legacy format since that's set in stone at this point.