Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 13:59:51 -0700, Carl Worth cwo...@cworth.org wrote: So what I'd love to see from here is a commit with a description like the above, and then a test case looking like your example. From there, I'd next like a new version of the commit that gets the intended behavior with less code duplication. I'll work on each of the above unless someone beats me to any of it. Let me know. I've now pushed out my own version of the MIME restructuring feature. It differs from what was presented here in avoiding the code duplication. It also provides properly nested mutlipart/* output for the --format=text case. That's not that I expect anybody to *do* anything with that nested output, just that it was cleaner and easier to fix both text/json at the same time, (and avoiding doing that is perhaps what led to the original code duplication). I also cherry-picked in a piece of later patch from Jamie so that the existing emacs tests still pass. And I updated the documentation for this new feature. So I'm happy with this new feature now, (which I know provides an essential part of the basis for the rest of the crypto branch). From here, I'm hoping that my review of the rest of Jamie's release-candidate branch goes faster. The general shape of the commits and commit messages looks pretty good to me, so I think it will. I think there are still features added here and there without corresponding test cases (multipart/alternative is one that comes to mind) and perhaps without updated documentation (--decrypt is at least documented---but I do think it's strange that it's documented to only work for json output). More from me tomorrow. -Carl pgpzsmwWIBXKT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: before, the output was a linearized version of the mime tree, in particular removing the multipart pieces and only enumerating the leaves in a depth-first walk of the tree. So a message like this: [snip example of change] Thanks, Daniel! That does make things much more clear. So what I'd love to see from here is a commit with a description like the above, and then a test case looking like your example. From there, I'd next like a new version of the commit that gets the intended behavior with less code duplication. I'll work on each of the above unless someone beats me to any of it. Let me know. -Carl pgpMZOFRqBDEc.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This message should itself be a comparably complex message, with a tiny attached image of a geek with a bike. Feel free to use this in the test suite (the picture and this message are hereby released under the same license as notmuch itself). Note that if the mailing list attaches a footer, the MIME tree will be even more delightfully complicated, for added fun and games. --dkg attachment: dkg-tiny.png signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes I tried creating a message like that but mine came out slightly differently: A└┬╴multipart/mixed B ├┬╴multipart/signed C │├╴text/plain D │└╴application/pgp-signature E └╴application/octet-stream I'll have to learn better how to control the emacs mail composer in order to understand how to get signatures to cover attachments if I want to do that kind of thing. would come out with three parts: 1) C 2) D 3) E That is indeed the behavior I see with master (for both text and json output). the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E Interestingly, this is not quite the behavior I get (with commit 373f352). With --format=text I'm now seeing: 2) C 3) D 4) E and with --format=json I'm seeing (I think this structure is right): 1) A 3) B 5) C 7) D 9) E 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). 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. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. All of this should be easy to get right with a careful test case or two. -Carl pgpi20C4xluPG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
lol, made my day! Simon On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote: On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This message should itself be a comparably complex message, with a tiny attached image of a geek with a bike. Feel free to use this in the test suite (the picture and this message are hereby released under the same license as notmuch itself). Note that if the mailing list attaches a footer, the MIME tree will be even more delightfully complicated, for added fun and games. --dkg ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 05:20 PM, Carl Worth wrote: Interestingly, this is not quite the behavior I get (with commit 373f352). With --format=text I'm now seeing: 2) C 3) D 4) E --format=text 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 nesting. 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. 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 signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth cwo...@cworth.org wrote: I'll have to learn better how to control the emacs mail composer in order to understand how to get signatures to cover attachments if I want to do that kind of thing. See mml-secure-message-sign-pgpmime to sign an entire message, as opposed to just a single part. 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. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. I think the two paths reconverge later in the series. Can you look ahead a bit to see if that concern is addressed? jamie. pgpWdZACwWbe8.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: See mml-secure-message-sign-pgpmime to sign an entire message, as opposed to just a single part. Thanks! That's good to know. (Trying here.) I think the two paths reconverge later in the series. Can you look ahead a bit to see if that concern is addressed? Daniel did point me to later in the series where the numbers are at least the same in text and json output. I've grabbed that state for generating a test case, (also with Daniels test message). And I'm now cooking up a new commit that will pass that test but with less code duplication than the current patch. -Carl pgpyr1d2eo38O.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
