Re: [gmime-devel] Putting GMime into Bongo
- From: Jeffrey Stedfast <fejj novell com>
- To: Alex Hudson <alex bongo-project org>
- Cc: gmime-devel-list gnome org
- Subject: Re: [gmime-devel] Putting GMime into Bongo
- Date: Sun, 07 Sep 2008 12:36:19 -0400
On Sun, 2008-09-07 at 15:07 +0100, Alex Hudson wrote:
> Hi Jeff,
>
> Well, I've put in the first patch which starts using GMime in Bongo: at
> the moment, just parsing RFC 2822 messages, but it was nice and simple.
> On LKML our old parser had a ~1% failure rate, so I suspect this is
> going to be a big improvement :)
I hope GMime's failure rate is 0% :)
>
> Jeffrey Stedfast wrote:
> > If you guys have any suggestions or features that you need, I'll try to
> > get them in for the next stable release (2.4.0?).
> >
>
> One simple thing has turned up immediately: there doesn't seem to be an
> obvious way to get a byte offset for the end of the mail headers from
> the start of a message. What I've done as a sort of hack is use
> g_mime_object_get_headers() to get a raw copy, and then calculate the
> length of that string, but I'm thinking that it would be nice if GMime
> just had an internal value somewhere that got set as it parsed the
> message (assuming it doesn't already).
Sounds like a reasonable API request :)
>
> I did look at doing a patch, but the state machine in gmime-parser.c is
> a bit beyond me at the moment: in particular, there seems to be some
> code to work with mails with malformed separation between header and
> content, and it looks like it springs it into a different state compared
> to finding the correct separator?
Yea, a while back I noticed that I had gotten a number of automated
messages that had no separation between header and body, it was just one
big splooge, so I added some logic to try and work around that.
>
> As another data point, I looked at the source for DBMail, and it looks
> like they have a find_end_of_header() in this file;
>
> http://git.dbmail.eu/?p=paul/dbmail;a=blob;f=src/dbmail-message.c;h=7f82b667698dd4090ef0fd6354c050e7b615102f;hb=HEAD
>
> ... which I assume is for the same reason I want the size of the headers
> too.
Cool, yea, I'll work on adding this feature.
Jeff
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]