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 <https://wiki.gnupg.org/EasyGpg2016>). 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. <https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard> and <http://www.embedded.com/electronics-blogs/beginner-s-corner/4023981/Introduction-to-MISRA-C>), 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... Cheers, Albrecht.
Attachment:
pgpLEL78hzH2N.pgp
Description: PGP signature