Re: [Gzz] PEG pts_content_types

[Benja Fallenstein]

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.

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?

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.

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.

- Benja