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

[Jeffrey Stedfast <fejj novell com>]

Alex Hudson wrote:
> Hi Jeff,
>
> Apologies for not getting back to you sooner - but wow on the progress ;)

Not a problem!

>
> 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?

it changes the size of the struct, which gets inherited from in the
"subclasses" (which means struct offsets in the subclasses would be
wrong). While a simple recompile would clear that up, it can't be a
drop-in replacement for the existing libgmime for applications built
against 2.4.

I *could* add header offsets to GMimeHeaderList, for example (which is
what my earlier patch did), because that is an opaque struct.

I still may do this for the header offsets, but for the content offsets
- I think it would be cleaner to have them be on the GMimeObject.

>> 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!

ok

>> - 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.

yea, makes the most sense to me too :-)

> 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....

For one of my other projects, I have to support gtk 2.8/glib 2.8 and so
I'm well aware of the frustration of having to make your software work
on older systems. To this end, I've been trying not to depend on too
recent a glib dependency with GMime as well, especially since I have a
feeling people use it for writing custom spam/virus filtering programs.
Odds are, however, that they are more-or-less happy continuing with
GMime 2.2.x (which at worst depends on something like glib 2.4?) so long
as there isn't some sort of exploit found in it or something :-)


FWIW, as far as offsets go - I'm also planning on making each field
offset available in the 2.6 API as well, since the parser already grabs
that information anyway and I can definitely see it being useful info.