Re: Upcoming GMime 3.0 changes

Hi Peter:

Am 21.06.17 22:03 schrieb(en) Peter Bloomfield:
I installed GMime 3.0.1 from git, and I have a patch against Balsa git master for building with it, keeping 
the ability to build with 2.6 through the magic of #if. It just adapts Balsa's current code to work with the 
new API, but even so it's a big mess, over 2k lines of patch, touching 32 files and creating 160 blocks of 
conditionally compiled code.

Ouch.  It's very interesting and encouraging to hear that you succeeded in compiling the sources.  But I 
strongly advise against using it through preprocessor conditionals.  It basically makes the code unreadable 
and unmaintainable, and has always been a source for funny (more or less, actually) errors.  Better create a 
new branch...

But it compiles and runs in at least one configuration, so it's available for exploring the new features that 
Jeff put in 3.0.

Which new features are you referring to?  I.e. what was missing in 2.6 for Balsa which is new in 3.0?

If we're going to need a single tree that can build with either 2.6 or 3.0, I could commit this patch.

See above.  *Please* don't do that!

It looks first for 3.0, with a fallback to 2.6--no configure option for choosing, although one could be 
implemented. Alternatively, we could make a stable gmime-2.6 branch and make master 3.0-only, which would 
make for a more convenient development process.

Why would we want to have an option for 3.0 in the wild?  Is there *any* disto which ships 3.0?  Brand-new 
Debian stretch (which typically will be the next Ubuntu LTS) comes with 2.6.22...

And, apart from that, what would be the /technical/ reason for porting now?  If I look at Jeff's announcement 
regarding the new features (I omit the pure API changes):

- Internal raw value header cache.  Really useful for other purposes, but is this of any importance for 
Balsa?  I don't think so.
- Crypto uses GpgME.  We have it in Balsa since more than a decade, completely bypassing the old gmime gpg 
interface, and it works perfectly.  We could remove or shrink some files, but does this justify the effort at 
this point?
- Tolerant address parser.  Again useful for other purposes.  But has this /ever/ been an issue in Balsa?
- GMime detects RFC 4880 in text parts.  Balsa does it since ages (using RFC 4880 is discouraged, though).

Did I miss something?

So, IMHO there would be no benefit at the expense of less readable, less maintainable and more error prone 
code.  This is definitely something which should *not* go into the master branch.

Since no GMime 3.0 packages have yet been released(?), and development is possible only for the intrepid git 
user, another possibility would be to open a bug and post patches there, until released packages enable 
easier testing.

Any suggestions about how to proceed?

I think your test code is a really very interesting feasibility study.  It might be an idea to create an 
"experimental" branch with it, so it's not forgotten.  But I think it is *not* suitable for any community 
package at this point.

If we want to make Balsa more popular, IMO we have completely different problems.  I don't watch other 
distos, but Debian and Ubuntu all ship with some 2.4.12 variant.  But this one will just stop sending 
messages at some (near?) point in the future as it relies on the ancient libesmtp library which supports 
(insecure) SSL 3 and TLS 1.0 only, so MTA's will probably simply refuse to talk to Balsa.

Package maintainers *hopefully* now look at Balsa's master branch, iirc you sent an announcement last year.  
Again changing master to something relying on non-standard packages is an extremely bad idea and will 
encourage maintainers not to put too much effort in something which looks like a quite unstable and 
experimental project.  Until Balsa disto packages silently die for the reasons above.

Looking at my personal agenda, I think the following points should be addressed shortly:
- Some improvements in the crypto code, in particular replacing the clumsy gpg code for talking to key servers by 
GpgME.  Goal: remove gpg config dependency, better user experience, preparation for EasyGPG which will rely on 
Gpgme keyserver interaction (see <>).  I'm working on that.
- Replace the low-level networking parts in libimap, depending on openssl, by libnetclient.  Probably much 
work, I'll look into it after finishing the first task.  Goal: drop openssl dependency (and its frequent 
security issues), as everything will then be in gio (i.e GnuTLS).

And, if everything has been tested, it would be time for a new stable release IMO, which should be promoted 
for inclusion into distos.

Oh, and I think we should also look into the code quality (see e.g. 
<> and 
<>), documentation and 
coding style.  Static analysis (FlexeLint or similar) would be great.  Not visible to the user, but improves stability 
and security.

Just my € 0.01, though, as always...


Attachment: pgpLEL78hzH2N.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]