On 2005-06-12 13:15:37 +0100, Julian Foad wrote:
> Vincent Lefevre wrote:
> >gzip is an encoding, but not a MIME type. From /etc/mime.types under
> >Debian:
> >
> ># Note: Compression schemes like "gzip", "bzip", and "compress" are not
> ># actually "mime-types". They are "encodings" and hence must _not_ have
> ># entries in this file to map their extensions. The "mime-type" of an
> ># encoded file refers to the type of data that has been encoded, not the
> ># type of the encoding.
> >
> >So, svn:mime-type should contain text/plain and there should be a way
> >to specify the file encoding (compression scheme). "utf8" is not an
> >encoding in the MIME sense.
>
> Hmm... I can't see how that would work in general. It could have
> made sense in MIME's original context - attachments to email
> messages - where the compression was perhaps temporary, to be
> automatically undone at the end of the transfer, but I can't see
> that making sense where MIME types are used more generally to
> describe arbitrary files.
The application could still perform the decompression (many can do
that when it is common to compress the file, e.g. "gv", "xdvi" and
"less"). It could also be the job of the application launcher if
there's one.
> For example, what about a Zip (as in PKZIP) file?
No, a zip file is an archive, so that it has its own MIME type
(application/zip). Ditto for tar (application/x-tar). So, a
.tar.gz file should have MIME type application/x-tar.
Well, some archive files may have other MIME types when it makes
sense (static libraries, Java classes and OpenOffice files are
just archives).
Also, if a zip file has only one file, then it can be seen as a
compression scheme, but this would be up to the user to decide
(at commit time, when setting the properties) how he wants the
file to be regarded
> That's a combination of compression and multi-file archiving. A
> single MIME type can't represent the content of all the different
> files in the Zip archive, so Zip would have to have its own MIME
> type. Then a single UTF8 file Zipped would have a MIME type of
> "Zip", and a single UTF8 file gzipped would have a MIME type of
> "UTF8 text".
And a UTF8 file encapsulated in HTML (e.g. using the "pre" element)
would have a text/html MIME type. I don't see this as a problem.
> Maybe that's how it is, but that seems awfully ugly to me and I
> don't imagine at the moment that that would be the right thing for
> Subversion to do.
>
> I'll try to read up on the standards and the current best practices
> on using MIME types to get a better understanding of the issue, but
> I may not get around to it any time soon.
One of the questions one may ask is how MIME types should be used by
Subversion. An advantage of considering compression schemes not as
MIME types is for svn diff for instance: the diff could be shown on
the uncompressed file (as the may be unwanted or may be slow, this
could be an option only).
--
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 17:30:02 2005