Re: [gmime-devel] Mapping MIME parts to byte offsets

[Alex Hudson <alex bongo-project org>]

Hi Jeff,

Apologies for not getting back to you sooner - but wow on the progress ;)

Jeffrey Stedfast wrote:
> After implementing the attached
> patch, I am now thinking that I might like it to be on GMimeObject
> instead, but I can't add it to GMimeObject w/o breaking ABI :-(
>   

Just out of interest, why does it break ABI? Can extra fields not be 
"tacked on the end" as it were?

> I had a couple of questions about behavior:
>
> - If you are ask for the message headers, presumably the begin/end
> offsets should be for the entire header-block, correct? (vs some sort of
> kludge to discount any MIME headers)
>   

Yeah, I think so - I'm really interested in the offsets within the 
message, so that if GMime tells me a particular header block is at bytes 
345 length 20 then I could just fopen the message, fseek to 345 and read 
20 bytes :)

Any kind of fiddling around trying to ignore the MIME bits could be done 
by the app itself if you have the other offsets I think, and I'm not 
much interested in that anyway!

> - But what if you ask for the toplevel mime-part's header offsets?
> should they be identical to the offsets given when requesting for the
> message? I presume this to be true, but I'm not sure.
>   

Good question. I think you're right; makes most sense to me.

As for the other bits on 2.6 in general - I'll try to make time in the 
next couple of weeks to look at some of the things we don't do right now 
but were planning we'd do in the future, particularly the MIME creation 
from web app side of things, but I suspect that GMime is very complete 
in that area already. The GIO stuff definitely does interest me and in 
terms of having a more modern glib I'm not fussed; but equally I can 
imagine it would be more of an issue for others....

Cheers,

Alex.