Re: [Gzz] PEG pts_content_types

[Tuomas Lukka]

On Fri, Nov 22, 2002 at 12:17:30PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >On Thu, Nov 14, 2002 at 09:03:51PM +0100, Marc Schiereck wrote:
> > 
> >
> >>Changes
> >>-------
> >>
> >>PermanentTextScroll has to be changed accordingly. There it
> >>will be necessary to determine the charset used in the body
> >>to set the appropriate charset for the String defined in
> >>load().
> >>   
> >>
> >
> >Like Benja keeps saying, we need to support eternally what we support now:
> >could you list the charsets intended?
> >
> 
> Hmm. This isn't really possible: in an email client, we should simply 
> support as much as we can (ideally all official IANA-registered 
> charsets, practically all that our Java supports). -- But you're right; 
> we want to be sure we can read in the future what we can read now.

Well, then you should say exactly this in the SPEC...

> I discussed this with Marc this morning and we thought it probably makes 
> sense to convert everything to Unicode when recieving it. The problem is 
> what to do when we receive a mail in a wrong character coding (which 
> happens)-- we *must* be able to re-construct it the way we received it, 
> so that a human expert can look at it and reconstruct it the way it was 
> originally. Ideas?

Because of this, it might be better to leave it as is; not mangling received
data is a pretty good principle ;)

> BTW, while your point is correct by itself, the reference to what I'm 
> always saying isn't really ;-). The Persistency Commitment does not 
> apply to applications of Storm in the same way: The point with Storm is 
> that if I create a block now, I can *keep* it eternally without great 
> fuzz. In 50 years I may not have an application that can *interpret* 
> them, but I can still naturally keep them and move them around and back 
> them up and retrieve them from old backups (possibly consolidating 
> multilple backups by adding together the valid blocks found in any of 
> them). Now if I want to read those blocks again, I can write an 
> application that can read them, because the data isn't lost. So app 
> persistence isn't as important as persistence on the Storm level.

Well, for me app persistence, especially for email apps, is every bit as
vital as storm block persistence.

> There's a good reason for this nitpick: Apps must be allowed to evolve 
> quickly; the Persistency Commitment, OTOH, is quite a burden actually, 
> forcing development of Storm to slow down. Applying the commitment to 
> everything would be too much of a burden; we should apply it to Storm, 
> which guarantees that even if we have totally different computers and 
> media in 50 years, as long as Storm is still used, we can still move our 
> blocks to the most current computer we're using, and *if we want to*, we 
> can write an application that can read those block. That's not to say 
> backwards compatibility is unimportant, but it is allowable for apps to 
> break it if they have a good reason to; it is NOT allowable for Storm, 
> as good as a reason may seem, and that is what the Persistency 
> Commitment guarantees.

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... an amusing idea: we apply the persistency commitment selectively 
to the important things...

        Tuomas