Vincent Lefevre wrote:
> On 2005-06-14 14:02:06 +0100, Julian Foad wrote:
>>Vincent Lefevre wrote:
>>>On 2005-06-13 17:56:52 +0100, Julian Foad wrote:
>>>>I think there is some confusion between "file encoding" and "transfer
>>>>encoding".
>>>
>>>No, this is the same thing (though a file could be compressed before
>>>the transfer...).
>>
>>Sorry, I simpy don't understand your point of view no matter how much you
>>say. We'll just have to disagree until someone else explains it in a
>> different way to one or both of us.
>
> Perhaps the Apache documentation?
>
> http://httpd.apache.org/docs-2.0/en/mod/mod_mime.html#contentencoding
OK, thanks. That helps to explain how content type is handled in HTML.
> In particular, it says:
>
> By using more than one file extension (see section above about
> multiple file extensions), you can indicate that a file is of a
> particular type, and also has a particular encoding.
>
> You can read "file" in the above paragraph, not "transfer". Note that
> here, the compression is not added by Apache, it is part of the file
> on the file system.
OK. So you're saying we should move closer to the way content type is notified
in HTML*, and add a "content encoding" to the meta-data of Subversion files, as
the first indicator of how to handle a file. If no encoding is specified for a
file, then the Subversion client program would look at the MIME type to
determine how to handle it. If an encoding is specified, then we could design
Subversion to decode the file before applying operations such as "diff" and
"merge" (and it would look at the MIME type to determine what to do after
decoding), and encode it afterwards. The user could be given the option of not
having this decode/encode step performed.
You must be implying that we should add this "content encoding" field, because
without it there is no point in knowing what MIME type the data would have
after decoding. I must have missed where you said this.
This may be a direction that we want to go in. I don't know. I was working on
the assumption that we had just one field describing the file's outermost type,
and that therefore that field would say that a file was gzipped data, but would
not say what kind of data had been gzipped.
I can't help feeling that HTML's two-level scheme (content-type and
content-encoding) lacks generality: for instance it can't handle more than one
encoding such as a text file that is gzipped and then uuencoded. In practice
this probably isn't much of a problem, but it still bothers me. I have for
years thought about designing a heirarchichal content-type description scheme,
but haven't got very far.
- Julian
[* Apologies if I'm saying "HTML" where I should be saying something more
general like "HTML family".]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 14 16:24:56 2005