gnu-arch-users
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]