Re: [Gzz] PEG pts_content_types

[Tuomas Lukka]

> 1. Add it to Storm verbatim as a message/rfc822 block.
> 2. Try to externalize the different body parts into own blocks, 
> referencing them through message/external-body, converting their 
> Content-Transfer-Encoding to binary, and for text/xxx blocks the charset 
> to UTF-8 and the linebreaks to \n. (If the conversion does not work for 
> some block, we'll probably just leave that body part in the 
> message/rfc822 block and interpret it as US-ASCII.)
> 3. Try to reconstruct the original, verbatim message/rfc822 block from 
> these blocks. (The id must match, which means the bytes must be exactly 
> the same.)
> 4. *If that worked*, delete the verbatim block. (If it didn't work, keep 
> the verbatim block for future use when extracting the email from Storm, 
> repairing a character coding etc. This is expected to be a relatively 
> unusual exception.)
> 
> That way, we have the convenient access as normal UTF-8 blocks, but also 
> the guarantee that we can go back to the original message format, 
> byte-for-byte, if we need to.

This sounds very good, especially if you can make the back-conversion
algorithm REALLY simple.

> Then, we only need PermanentTextScroll to support:
> - text/plain with charset UTF-8
> - message/rfc822, which is interpreted as US-ASCII
> 
> Alternatively, we can have a subclass of PTS, MailTextScroll, which 
> would use message/rfc822 instead of text/plain. I think I like that.

Sounds good.

> >Of course. I fully agree. OTOH, email is one such basic function that at
> >least for the blocks that store received emails, it probably would make
> >sense to do the persistency commitment.
> >
> 
> Hmm, I do agree, but thinking about this, I feel we shouldn't commit 
> ourselves to something at this point... I'd say prototype this, then 
> before moving to using it as our own main email system give it an 
> overhaul, spec well and then decide whether to apply the commitment.

Sounds also good.

        Tuomas