Re: [Gnu-arch-users] Re: How does arch/tla handle encodings?

[Marcus Sundman]

On Saturday 28 August 2004 03:31, Michael Poole wrote:
> Marcus Sundman writes:
> > Now, you may argue that this isn't a big problem, since such guesses
> > are correct more often than not. Or that incorrect guesses aren't
> > really that important. However, if this can be fixed easily, then why
> > on earth would you not? I just can't believe the mentality of you
> > people.
>
> You are kidding, right?  You want arch to impose a particular solution
> for a rather rare problem on users when there is no consistent or
> clear technical way to solve the problem?

What on earth are you babbling about? Distorting, or even losing, the 
semantics of a file by throwing away the encoding info is by no means a 
rare problem. There exists only one solution to this, namely to not throw 
away that info. There is a very consistent and clear technical way to solve 
this problem.

I can't fathom your delusions about this issue. Exactly what is it that you 
have a hard time grasping?

> Many people whine about systems that do not take special care of some
> character encoding scheme (or set of schemes).

Such complaints (or "whine" as you so eloquently put it) are completely 
warranted more often than not. The problems are usually the consequence of 
having complete morons design things. Apparently many developers have a 
hard time understanding the relation between strings, bytes, encodings, 
character repertoires and glyphs. I can't for my life understand what could 
possibly be so hard to understand.

> None of them seem to know how (for example) tla and emacs and Apache
> should communicate to each other the information of encoding scheme for a
> text file.

Well that of course depends on the protocols used. If you communicate with 
apache over http then you use the Content-Type header field, as per RFC 
2616. If the communication between tla and emacs uses some custom protocol 
then that protocol obviously have to support something similar. If you use 
files (e.g. if tla reads files saved by emacs or vice versa) then it 
depends on a combination of the file system, the OS and the applications. 
Most file systems today don't support a mime-type attribute (or similar) 
and almost no programs do. Instead they use a global encoding environment 
setting that all programs, and the file system, use. In those cases you 
obviously have to transcode the files that can be transcoded. The only 
thing there is to do for the rest of the files (until the OS/app/FS 
combination gets better) is to be ready to provide the necessary 
information upon request. Exactly what about this is it you find hard to 
grasp?

> How do you think it should be done in a way that does not break when
> "normal" applications copy or move the file?

If the FS supports it there is no problem. Otherwise there is not much one 
can do, other than to have all files in the local system encoding wherever 
possible.

> In other words, I disagree that the problem can be fixed at all (much
> less easily) by merely adding support for per-file metadata to arch.

Quite frankly, I couldn't care less if you agree or not. I know that if tla 
provide mime-type info (e.g. like svn does) and proper hooks then I can 
solve the problem in my projects. I'd rather not write all that wrapper 
code, but it sure would be better than nothing.

I simply cannot believe that I actually have to argue for not throwing away 
the encoding info. Never in my life have I met such backwards-striving 
people as some of you are. I mean, I relay obvious conclusions agreed on by 
every person that I know have given the issue a bit of thought, and you 
people fight it with all you've got, claws and teeth. Unbelievable.

I had an "encoding handling proposal" all ready, but I don't think this 
community is at all interested in this whole issue, so I'd better just let 
it be.

Good luck with these morons, Tom Lord. I truly feel sorry for you if you 
have to endure this kind of illogical and pointless resistance normally.


- Marcus Sundman