Hey again,
I mentioned GMime in my previous email. I think I'd like to discuss this
specifically a bit more.
http://spruce.sourceforge.net/gmime/
One thing I just noticed, which I've never realised before, is that both
the Queue and Store agent have MIME parsers inside them. Fundamentally,
they look very similar, so I'm assuming that when NMAP was originally
split, the MIME code was copied into both and the Store code has evolved
a bit.
I don't like this for a number of reasons; primarily, if we run into
bugs with this code then we're having to fix it in two different places
which aren't quite the same.
I downloaded the GMime source code, and honestly to me it looks
extremely well written, and a lot of the work-arounds for different
clients are commented in the source code (e.g., a comment from the
address parser: "some Japanese cellphones have email addresses that look
like [EMAIL PROTECTED]"). Fundamentally, this buys us a number of things:
1. a complete, tested and battle-hardened MIME parsing system;
2. a number of useful utility functions: mail address parsing, for
example;
3. support for looking at things like S/MIME, OpenPGP;
I can think of a number of downsides to using this:
1. the extra dependencies that I mentioned before (although it seems
GMime is a lot more common than I assumed);
2. work involved with switching to a different API;
3. potential incompatibility between GLib and XPL: for example, is
gfree() going to work happily alongside MemFree()?
4. steps on the toes of code we already have: e.g., it hooks into
iconv, which is what our StreamIO API is based o
5. any bugs we find we're going to be hunting for in someone else's
code or relying on GMime hackers to help find/fix;
But this is something I'm now quite interested in exploring, because the
mail parsing is something that I feel is a weak spot, and it's something
I'd very much like us to not have to re-invent.
I'd love to know what others, particularly you Pat ;), think about this.
I'm also going to drop the GMime hackers a note as well, asking if they
can think of good reasons we wouldn't want to do this.
Cheers,
Alex.
_______________________________________________
Bongo-devel mailing list
[email protected]
https://mail.gna.org/listinfo/bongo-devel
