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

[Alex Hudson <alex bongo-project org>]

Jeffrey Stedfast wrote:
> Alex Hudson wrote:
>   
> > So instead of values being stored, we grab the substream, reset it to
> > find the start and then ask it for the length?
> >     
>
> Or you can look at the bound_start and bound_end members on stream and
> do the math :-)
>   

That too :D

> I did, however, think of a bug in it last night... if you change the top
> level mime part's headers and write the message to disk, I suspect that
> it won't reflect the changes because the message will write out the
> cached stream. Easy fix and not something I expect you'd have to worry
> about in Bongo.
>   

Well, although I don't care about that right now, in the near future I 
might - we've been toying with the idea of putting MIME composition into 
the server, mainly so that parts of the mail system have a relatively 
easy and safe way of twiddling mail on the way through. As one example, 
a web application would be able to draft mail without having to have a 
server-side session doing the compose for it (say, putting the mail text 
together with an attachment), and then on sending you could have a 
daemon which adds global signatures without having to re-compose the 
message itself. If that makes sense.

I guess it raises some interesting questions about the semantics of your 
new API, though. As a stream, is GMime going to care if I twiddle around 
with it seeking/resetting, etc? Does it absolutely have to be a 
sub-stream of the main stream, or could you in fact replace the original 
sub-stream with a new stream as a way of replacing content? That would 
be a pretty simple way of putting new content into the mail, and the 
later streams are still "correct" (at least, I think, given the brief 
thought I've given it).

Another interesting aspect of this, slightly veering onto a different 
topic, is whether or not there is a sensible persistent caching strategy 
for GMime messages - can I save them somehow and then restore them later 
to use again without having to re-parse the message? I could see that 
being useful if you had a large message, say with an attached e-mail 
which is pretty large, and wanted to just get at the headers. Maybe it 
could be possible to lazily restore the cached streams based on 
serialized information from a previous parse attempt or something...

Perhaps for another day. :)

Cheers,

Alex.