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

[Michael Poole]

Marcus Sundman writes:

> On Saturday 28 August 2004 20:02, Michael Poole wrote:
> > 1) You have not defined any specific problems that you want to solve,
> >    then you assume that we are too stupid to solve your problem.  So
> >    far you have made complaints analogous to "arch should solve the
> >    code attribution problem."
> 
> First of all I originally only tried to get answers to a few questions, and 
> almost immediately people started bashing wildly.
> 
> That said, the problem here was very specific. No link in the chain should 
> lose the essential piece of metadata referred to as "encoding info". If it 
> is lost then there is no way to get it back. How is this not specific?

Where is this metadata established?  I know of no editor on my Linux
or Windows machines that records "encoding info," except within the
byte stream of the files they work on.

Keeping "encoding information" is more of a feature request than a
problem to solve.  The kind of specifics I would like is a description
like "I commit a file using ISO-8859-15 into arch, and someone who
gets that file and opens it using an ISO-8859-1 editor gets the wrong
non-ASCII characters."  The obvious question about that case is:
Suppose arch records and can report the encoding.  How does that help
a user who needs arch's assistance to discover the encoding?

> > 2) You insist that the best way to solve an uncommon problem (most
> >    users have no confusion about encoding systems) is by arch
> >    providing a special-purpose hook.
> 
> I have insisted no such thing. Also, in my experience the problem is way too 
> common.

If it is not a special-purpose hook, what generic mechanism exists
that permits arch to record this metadata?

I do not discard the value of your experience, but "way too common" is
both subjective and vague.  My experience is to the contrary -- mostly
because people tend to know what coding system is used by files they
open or edit -- and I do not know of any reason to accept your
experience as more accurate than mine.

> > If you want us to take you seriously, it would be helpful to be very
> > specific about how and where you believe your problem occurs and why
> > arch is a good place to solve this problem.
> 
> The problem occurs when one link in the chain behaves badly. Arch is one 
> link in the chain. Exactly what is it that you don't understand?

As I explained above, I still do not understand what specific problem
you want to solve.

There is a chicken-and-egg problem with standards to record this:
until some standard storage mechanism exists, tools will randomly
destroy the metadata.  But until tools exist, many implementors will
reject a proposed storage mechanism as not truly standard.

The main problem I see with common filesystems is that, in the general
case, the metadata has to be stored in a separate file.  When multiple
streams per file are supported by more operating systems, a meaningful
mechanism can be used.  Until then, there can be only fragile kludges
to address the problem.

If your proposal describes how to use EAs, named streams, or whatever
other OS/FS-specific mechanism implements per-file metadata, I would
like to hear it, and I apologize for offending you.

Michael Poole