Re: [gmime-devel] git master is now for 2.99.x development

[Jeffrey Stedfast <fejj gnome org>]

On 2/3/2017 12:37 AM, Michael Gratton wrote:

On Wed, Feb 1, 2017 at 11:45 AM, Jeffrey Stedfast <fejj gnome org> wrote:

Some of you may have noticed already, but git master is now for 2.99.x development that will lead up to a 3.0 release.

I've created a gmime-2-6 branch for the old 2.6 API.

Thanks for the heads-up!

No prob

Over the past day or so I've been taking a wrecking ball and smashing parts of GMime into oblivion in order to improve the API and/or to fix long-standing design flaws (such as raw header caching). I'm going to *try* to keep master in a usable state, but I would not bet the family farm on it, so be warned. For a rough idea of what my plans are for 3.0, you can check out the TODO file.

The only thing I can think of off the top of my head is renaming g_mime_message_[g,s]et_sender() to g_mime_message_[g,s]et_from(), since IIRC it's actually working with the From header. It would be nice to have some convenience functions to get to the Sender header as well.

Already implemented :)

This bothered me, too.

I'll go through the TODO in a bit more detail and grep Geary's codebase for GMime related stuff when I have a moment, and let you know.

Cool. I'd appreciate any feedback on the current API's and where they could be better.

One of the things I've done (besides the sender/from change) is to make iterating over headers simpler. I hated the Iter approach. An indexed approach is so much easier :)

I also got rid of the header-list stream cache and am instead caching the raw parsed header values on a per-header basis, so adding or removing a header no longer causes all headers to be re-folded. It also means that changing, say, the To header won't cause all other headers to be re-folded either.

Moving to GpgMe for the PGP support instead of maintaining my own wrapper is also on the TODO list (actually, it might not be in the TODO file yet... I should check that and add it if it's not). This and the whole header-caching problem were the 2 biggest reasons for starting a new development branch for me.

I think I'd like to kill off the whole g_mime_get/set_user_charsets() API and maybe use something more like MimeKit's ParserOptions API:

http://www.mimekit.net/docs/html/T_MimeKit_ParserOptions.htm

For specifying the charset to use when encoding, maybe I can modify those API's to take a charset parameter.

Someday I need to write an auto-C# to Glib converter so I can port MimeKit to Glib and replace GMime with that :)

(My C# MimeKit API is beautiful)

I'm also thinking of moving development to GitHub in order to open GMime up for Pull Requests so I can avoid dealing with patches via email. Is hosting GMime's git repo on git.gnome.org making it more difficult for people interested in and/or already contributing?

Geary's in the same boat, so it doesn't make too much difference to me either way. Putting my tinfoil hat on for a moment though: Maybe it would be nice if one proprietary organisation didn't have such a large monopoly on libre source code hosting? :)

The good thing about git is that it's trivial to migrate to another hosting site if it should ever be needed :)

There's always places like GitLab, BitLocker, etc.

The only reason I'm thinking of moving to GitHub is that's where my other side projects are hosted at the moment and it makes things simpler for me (plus pull requests are really nice). I also assume most people have GitHub accounts and/or could easily create one (it's free), whereas getting a GNOME account is not as trivial.

Jeff