Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
>> > * Is just adding the encoding to svn:mime-type the correct
>> > * slution, or should I use it only as a temporary hack?
>> > * Should we introduce a svn:encoding property instead?
>>
>> No idea here; maybe Greg has an opinion.
>
> I _think_ tacking the charcoding onto svn:mime-type is the thing to
> do...
Groooaaaaarr. I had this very same question back in the days of
yore. What _I_ was told was _not_ to do it. Then we still had the
"svn:encoding" property lying around unused. And the reasoning
presented to me was:
The svn:mime-type property is a MIME-type, not a Content-Type, hence
it should not carry charset information.
So, first I'm commenting on this on how I was told before - then I'm
commenting something of my own.
> Reasoning:
>
> If we add a new property, then people will always have to ask
> themselves "Do I use svn:mime-type to specify the charset encoding,
> if I'm also specifying a mime type anyway, or should I *still* use
> the svn:encoding property? And what would happen if I did both but
> they differed?"
The svn:mime-type property should only carry the MIME-type, no
additional fields. If needed, it can be validated that it does not
contain them. Charset encoding is a separate issue.
> Conversely, if you're setting the charset encoding explicitly, it's
> a no-brainer to set the mime type while you're at it. After all, if
> you can't decide on a mime type, then "text/plain" is your friend
> :-).
Yes, setting the MIME-type is no problem - having to set it when
setting the charset is not a problem.
> In other words, since people will guess that it is *possible* to do
> it on the mime-type anyway, we should just make that the official,
> advertised way to do it.
Yes, I did guess so as well - but if svn:mime-type is a MIME-type, and
not Content-type, it should not carry any extra fields. That's a
rationale the users can buy as well.
But then, what I really think about the matter myself... I'm not
entirely sure what's the best way to proceed. If we say that
svn:mime-type is really a Content-type, we open up a lot of
possibilities. For example, adding a file to the repository and
setting svn:mime-type to 'multipart/mixed; boundary="fooie"'. Then
what about 'image/jpeg; filename="somethingelse.jpg"'. Ofcourse, those
should not be any different from any page you happen to stumble on on
the web, but they might provide some interesting results
nevertheless. Then, I'm not sure what the stance on re-encoding things
is, but suppose some day the client or web-browser can request the
files with different encodings, perhaps by using content
negotiation. That means that our DAV needs to dig out the original
svn:mime-type on the file in the repository, parse out the charset
from there, re-encode the document, and then tack on a Content-type to
the client that has the charset parameter changed accordingly.
Then on the other hand, if we separate charset or encoding to it's own
property, how will we support all the weird cases when you need to
have parameters on the MIME-type? It would seem like a bad solution to
have everything but the charset parameter in svn:mime-type, and then
that separately. Or ofcourse we can just decide that there is a
MIME-type and then a charset for text types and nothing else. But that
might be an unnecessary restriction.
OK, I just woke up so I'm rambling about all the possibilities. But
the thing is, that atleast I'm not entirely sure what the
svn:mime-type should be used for - is it an entirely repository
internal thing - or does it specify the behaviour to external browsers
only through DAV - or what it should do.
But, to conclude this, I have a proposition. For now, let's make
setting svn:mime-type to 'text/plain; charset="UTF-8"' official - but
let's not close the book entirely on this thing yet. Right now, it
would be the easiest solution and it gives the most flexibility -
everything else requires some implementation of new things.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 09:12:49 2002