Message-ID: <4DD19712.3000203@fifthhorseman.net>
Date: Mon, 16 May 2011 17:28:50 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9
MIME-Version: 1.0
To: Carl Worth <cworth@cworth.org>
Subject: Re: MIME restructuring [was: Re: release-candidate/0.6]
References: <8762pn7gth.fsf@servo.factory.finestructure.net>
	<874o4zczr8.fsf@yoom.home.cworth.org>
	<87wrhvyqfn.fsf@servo.factory.finestructure.net>
	<87r57ybcna.fsf@yoom.home.cworth.org>	<4DD18DFE.7090206@fifthhorseman.net>
	<87ei3ybawo.fsf@yoom.home.cworth.org>
In-Reply-To: <87ei3ybawo.fsf@yoom.home.cworth.org>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enig785DCD2A67D604C54F1BF143"
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list
Reply-To: notmuch <notmuch@notmuchmail.org>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig785DCD2A67D604C54F1BF143
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 05/16/2011 05:20 PM, Carl Worth wrote:
> Interestingly, this is not quite the behavior I get (with commit
> 373f352). With --format=3Dtext I'm now seeing:
>=20
> 2) C
> 3) D
> 4) E

--format=3Dtext should only show the parts that are readable in text.

the ultimate goal is to get the part numbers aligned across all --format
choices, regardless of the ability of the format to show the actual nesti=
ng.

> So that explains some of my confusion. The behavioral change of this
> commit is really only impacting the json format, and not the text. That=

> wasn't clear from the commit message (and I had only been doing my
> testing with the text backend).

It should ultimately affect the numbering in all parts.  There's no way
for the text part to do anything like the nesting that we're doing in
json, though, due to the output format.

> This seems to be justifying my fears about the code duplication---the
> two code paths are already divergent, (which means that things like
> notmuch part-number identifiers cannot be used between the different
> formats). I'd like to fix that by preventing the code duplication.
>=20
> Also, both paths seem to be suffering from some excess part-number
> incrementing somewhere.

The confusions you outline were fixed (by me, iirc) somewhere later in
the crypto tree.  I did not want to tamper with dme's crypto branch
directly (though i now suspect that's what i should have done).

i'd give you a commit ID, but i suspect you're sufficiently rebased that
this wouldn't be helpful.

	--dkg


--------------enig785DCD2A67D604C54F1BF143
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQJ8BAEBCgBmBQJN0ZcSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD
Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp+tsP/3kGtBOzMX8qit1v8ekv3StY
vDHddazbO2b9/2626YhAcW8uAyKw2P7Oz814JeMTutsxxTnqng9T6kymAg5q4ThN
M14L3LklWs5sNqT9ODiTmtkm//lLJvKbit3s5v5E5udpIMEDEJhPwHhGUjyKN8W2
HLy67+RqxPe7Y4KQf/2RbOXGPsatfEmMpjzn46MXlGdy6TFf6BJV/pEttCAO+R8/
7vho7CDjvZ0U5IveGhHl3oaEZqNn3I1nAOEGwo0EYjUYyay2ngqCmIIHPC0/pAQF
4rT58+Fh4OqqEFJW2/bcWa1S9YmwZRcZg0kLcj+ytN87QoDsx98DLSqVTOy14KCv
GVxcRd6EagBG268uIOMuOMH5WelNWoBSMY6Eb+2eSF5DjjTecj4VhapC95AZ4xl3
xKy6P0AkkocbM7S2RTUA9sSxmbW9E14sYLu1FCS4MrtYfX18kdM0HzM1I+auZp9f
UZ0tSqmpW29pGGR3zGtUv4Ft3x+D7N8d1Kjde5nK/0Dm1pqcB2w/bv2CmCrXlCXA
GlMsaXc3y2q8EtBIoebLCMPwqoOlhYu3crkAsPnVimUj8p3J/KX9hIIwJrGbC/Jh
sgmeJFsA3UZo0AYmcjkNJcsLFq2he+myhdeMeCH6E2pINeJp3RzPU8+xWfxJCB/B
ZTdPICDGydODIFePMMci
=XFjj
-----END PGP SIGNATURE-----

--------------enig785DCD2A67D604C54F1BF143--