[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Encoding handling proposal
From: |
Marcus Sundman |
Subject: |
Re: [Gnu-arch-users] Encoding handling proposal |
Date: |
Mon, 6 Sep 2004 03:04:13 +0300 |
User-agent: |
KMail/1.7 |
On Monday 06 September 2004 01:42, Michael Poole wrote:
> Except for the Auto-Filter idea, similar issues have come up in the
> past in the context of arch's inventory of files. I think that is the
> natural place for arch to know about file formats -- whether the
> inventory uses MIME content-types or something else.
Sorry, I'm not very familiar with the internals of arch. Do you mean that
each inventory entry should get a third field, 'Content-Type'? Or do you
mean that one should have an additional inventory entry for each file, and
then somehow link the two? Or do you mean something completely different?
> I share Stefan's concerns about non-transcodable code points.
That would be an issue only for people who actually set 'Auto-Filter' to
'true' on any file(s). I don't think Stefan would do that.
Also, I don't see a problem with enforcing people on my projects to use
encodings and/or formats that support the characters that are used, without
having to enforce a particular encoding.
Now this problem is "fixed" by forcing everyone to use the same encoding for
a given file. In my proposal I extend this to also allow other compatible
encodings and/or formats that support escaping character codes (such as
java source code).
> However, if arch's format handling is done properly, it can let each
> of us implement archives that work the way we believe they should, and
> let us work on each other's archives without problems. That ability
> is more important than one of us convincing the other of The One True
> Approach To Transcoding.
That would of course be the best alternative, provided that such a solution
could be found.
> Perhaps once xl is implemented, it would be an appropriate platform
> for format-specific diff/patch utilities.
Perhaps, but not necessarily. Filetype-specific patch formats could be made
possible with xl, by having each changeset include xl code for interpreting
all custom patch formats in that set. This might not be feasible, though.
- Marcus Sundman