On Wed, Jul 21, 2004 at 04:06:36PM -0500, kfogel@collab.net wrote:
> No, we didn't get the idea of properties from DAV. We knew we wanted
> key/value pairs even before we'd heard of DAV. Now we are imposing
> limitations on the keys, because of one (out of three) RA protocols.
Well I didn't set the limitations. juliafoad added it in r7528.
> I'm not sure it has to wait until 2.0. We could add the feature
> compatibly with a new "svn:quoted-propname:" prefix. (I'm being
> verbose; obviously it doesn't have to be that long.)
>
> Since Subversion owns the "svn:" namespace, we don't have to worry
> about compatibility with older clients *or* servers. No one else is
> creating "svn:" properties, and if they are, it's in violation of a
> long-published standard.
>
> With this enhancement, anytime someone sets a property whose name
> contains special characters, we transform it into
> "svn:quoted-propname:<quoted-str>" for transport. In the actual
> working copy, and in the repository, it does not need the quoting,
> because our storage formats there can handle the real names. However,
> if an older repository happens to keep the quoting, that's okay! Old
> clients will simply fail to unquote it; new clients will correctly
> unquote it. No one will crash, and all information will be preserved
> in one of two possible forms, until eventually everyone is upgraded.
Do we really want to go down paths like this? It sounds really really
ugly. And for what? How many people have asked for property names to
be able to support slashes? So far we've had one complaint on IRC
because he was trying to change a property that SVN::Mirror set. As
ghudson is fond of saying I don't think it's worth the complexity to
solve until it proves to be a problem.
And this isn't a problem. The restriction on the names has been in
there for nearly a year and hardly anyone has noticed or complained.
How difficult is it to pick another name in the valid namespace? Use -
or . or _ instead of /.
Further, your suggested solution is a totally drive by suggestion. How
exactly are you going to quote it? You could use base64, but jeez how
ugly. Can't use URI encoding because % isn't a valid character in XML
element names. You could make up your own encoding scheme, but again
how ugly.
The only other option is to use another special namespace where you
place all the of the name in the xmlns URI (which of course is URI
encoded) and then decode that and throw away the element name, e.g.:
<P:customprop
xmlns="http://subversion.tigris.org/xmlns/encoded/foo/bar%20whatever">
But ohh we did something really silly and we barf in the old clients if
they see a namespace they don't know about. Whoops can't do that.
What about putting them in the existing namespace won't that work?
<P:customprop
xmlns="http://subversion.tigris.org/xmlns/svn/quoted-propname/foo/bar%20whatever">
Oops that won't work either. Old clients will once again think it's a
different namespace. And even if it did work they'd think there were
gobs of properties named "customprop".
So why don't we do the xmlns trick I showed above and make servers and
clients negotiate if they know about it. What a great idea. Except DAV
is stateless. We have the OPTIONS method. But we don't always call it
and the only way we have of putting flags in it is also really ugly.
We could try the new way and if it fails fallback on the old way. But
we do dozens of PROPFINDs in some operations and that could
significantly increase our round trips against old servers.
There is no way to do this that is reasonably backwards compatable and
elegent. Believe me I tried. I finally gave up and worked around the
colon issue.
> I'm not saying this enhancement should delay 1.1 or even 1.2. I am
> merely asking if anyone disagrees that the situation is a bug, and
> secondarily asking if the above method seems like it would fix it.
No I don't agree it is a bug. We've explicitly disallowed these names.
Right or wrong that's the way it is until 2.0.
> It seems quite reasonable to me that people want "/" in property
> names, just as they want ":". We've already had real-world examples
> of both.
Sure it seems reasonable enough. But here's the deal. The colon
properties were already being allowed by the client software. They only
failed to work in one specific case and then only as a revprop. So many
people were probably using them completely unaware of the problems with
them. I suspect very few people set revprops other than the ones we use
internally (svn:log, svn:author, etc...).
But the / is an entirely different situation. It's disallowed by the
client library already. It has much more serious consequences if it
gets into a repo. It doesn't just fail in some obscure case. It will
cause operations involving it to have completely invalid XML.
The bug is that we're allowing people driving the repos/fs layers
directly to set properties that are invalid as far as our client libs
are concerned. I suppose someone else might want to use these libs for
something completely different that might not care about our RA issues.
But I don't see what choice we have.
> Good point.
>
> I certainly agree that we should decide on a valid syntax for property
> names (and values, for that matter), among other things. But the
> limitations encouraged by DAV are far too narrow, and we shouldn't
> settle for them unless we have absolutely no choice.
Well I think we have. You just don't like it. :)
Of course Julian's log for the addition said it was easier to make a
restrictive set and expand it later. That sounds really true. But in
this case it just isn't the case.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 22 02:15:38 2004