Re: [gmime-devel] Porting code from gmime 2.6 to 3.0

[Jeffrey Stedfast <fejj gnome org>]

On 5/1/2018 1:38 PM, Casper Langemeijer wrote:

Although I'm still working on it, it would be awesome if you could review my changes here: https://github.com/langemeijer/dbmail/commits/upgrade-to-gmime3 I've been a professional software developer for over 20 years, but I don't have much experience in writing C code. It's mainly arduino and other small projects. I'm learning and really appreciate feedback. I try to compensate lack of experience by working in the open, and exercise very verbose communication, leaving my train of thought into my communication and commit-log.

Added a comment or two on your github commits (nothing major), everything else looks good to me.

I've committed a todo document in commit https://github.com/langemeijer/dbmail/commit/850976c that you might recognize as a portion of your own porting guide. In every commit I've made when I solved an issue I removed that portion of the guide. When I reached the bottom I started adding things to the document that were not in the porting guide. My commits are small and focus on a single change.

Cool, glad you found that doc useful. Hopefully I didn't miss anything - I tried to keep it up-to-date as I went and made changes.

I'm not entirely sure about this commit: https://github.com/langemeijer/dbmail/commit/5b3a597 because I'm not sure what that method was doing there in the first place. Maybe you could enlighten me on this.

That looks like it was a hack that should not be necessary anymore. What it did was to clobber the raw header cache of the top-level MIME part. The reason for this is probably because that code was going to respond to a request for *just* the MIME part and/or its headers.

The problem with the header cache was that it included the raw *message* headers as well for the top-level MIME part (because the top-level MIME headers are intermixed with the message headers).

This is no longer necessary because GMime now tracks the byte offset of each header and is therefore able to reconstruct the proper ordering of message and MIME headers when writing out the message and the MIME part no longer has any of the raw message header data.

TL;DR: it was a hack around a hack in GMime :p

I find the gmime library very easy to work with, the documentation is good (But I have some improvements that I will PR when I'm done) , and the tests are very welcome examples of how to use the library. Also I can see that the api changes you made make good sense. Thank you for your work and your time.

Thanks, I appreciate that you think so :)

Also I welcome any doc fixes you have. I'm sure there are lots of improvements that can be made there.

Jeff