[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] PEG pts_content_types
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] PEG pts_content_types |
Date: |
Tue, 26 Nov 2002 09:22:12 +0200 |
User-agent: |
Mutt/1.4i |
> 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