On Tue, Jul 8, 2008 at 4:15 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> David Glasser wrote:
>>
>> On Tue, Jul 8, 2008 at 8:58 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>>>
>>> "David Glasser" <glasser_at_davidglasser.net> writes:
>>>>
>>>> On Fri, Jul 4, 2008 at 1:30 AM, Dag-Erling Smørgrav <des_at_des.no> wrote:
>>>>
>>>>> - Like it or not, svn:charset is already in use; formalizing it is the
>>>>> path of least resistance (though I understand your annoyance at the
>>>>> encroachment on what I understand is a reserved namespace)
>>>>
>>>> I don't think that the Subversion project needs to negotiate with
>>>> hostage-takers.
>>>
>>> Heh :-).
>>>
>>> But, as much as I enjoyed David's comment, the OP's sentiment is right:
>>> however we got here, here is where we are. (Besides, he wasn't
>>> proposing negotiation.)
>>
>> In all seriousness, though, I highly suspect that any group of
>> projects that are so lax that they don't even bother to understand
>> that svn:* are the only properties they *aren't* allowed to use would
>> also have failed to resolve all the issues discussed in this thread.
>> In that case, using svn:charset for a potential new property would be
>> the absolute *worst* thing to do, since it would conflict with
>> poorly-specified prior use.
>>
>> Anyway, if the main problem with the svn:mime-type solution is that
>> it's annoying to parse (which is true), then why don't we just add an
>> svn API that extracts the charset= from a given mime-type string? (I
>> guess there's still the autoprops issue, but perhaps there is a more
>> general fix to autoprops that could deal with this.)
>
> So, I don't think this has been noted so far in this thread, but we've been
> here before:
>
> http://svn.haxx.se/dev/archive-2002-08/0674.shtml
> http://svn.haxx.se/dev/archive-2006-03/1182.shtml
> (more?)
>
> I'm personally in favor of using a distinct property for this stuff, and am
> not terribly concerned about the sorts of compatibility issues that doing so
> would cause for folks (including us) who today use svn:mime-type -- which
> was intended to be a MIME media type and subtype, not a full-blown
> Content-type HTTP header value -- as the latter.
>
> That said, I don't think "character set" is the right nomenclature. Wouldn't
> svn:encoding be the more accurate description? (And let's just ignore for a
> minute the "other" interpretation of "encoding" proposed in
> http://svn.haxx.se/users/archive-2005-08/0139.shtml, shall we?)
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
I don't really know enough to have an option on what the correct
approach is, but I do agree that more thinking needs to occur.
This svn:mime-type discussion seems similar to (or at least related
to) the svn:mime-type discussion that went on not too long ago about
identifying binary files (and a possible property to help _really_
know if the file is textual or binary regardless of the intended use).
I ranted on that about re-purposing svn:mime-type for unintended
uses.
As in that case, it seems to me that it's cleaner to have the actual
use cases separated out (charset, binary, base-mime-type, whatever)
and then use whatever info is needed to construct the Content-Type on
the fly as needed).
And, whichever why this leads, I think the autoprops could definitely
use some revamping. Is that something that could happen with 1.6? By
this I mean, if I (or someone) beat on it and found something people
like, would it be a candidate for inclusion in 1.6 or 1.7, or would it
have to wait for a 2.x release.
- Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-09 01:33:31 CEST