On Mon, Oct 18, 2004 at 05:29:25PM -0000, kfogel@tigris.org wrote:
> Assign to self, mark as started.
>
> By the way, I'm focussing on a long-term solution for permitting
> colons, since people already need to use those (e.g., "svk:",
> "cvs2svn:") and we know our current solution is not completely stable.
> I'm working on the detailed proposal right now. While it will be
> general enough to allow any character in a property name, I'm not
> proposing that we actually allow all those characters yet. We can
> start by just encoding colons, while continuing to disallow all other
> non-XML-namespace-safe characters. The point is to get a permissive
> decoding mechanism deployed, so we have the option of unrestricting
> the other stuff later.
>
> Detailed proposal coming soon.
Karl,
We've been down this road before. I'll be so bold to say that you're
wasting your time and that I'm probably going to -1 (veto) any proposal
you have. Here's why...
First and foremost this problem is the greatest for non-svn client
implementations (i.e. DAV clients). These clients may be using XML
parsers that enforce the XML namespace recommendations. This is
unfortunate but understandable.
Any method of fixing this requires encoding. Because property names are
passed as XML elements there is no way to encode the data such that a
valid XML parser will automatically decode it for us. This means that
we must encode our data before generating the XML and then decode it in
the client after the XML parser is done.
Let's consider that we have 3 classes of clients we need to support with
this change:
* Old SVN clients that don't know about encoding of property names.
* New SVN clients thta do know about encoding of property names.
* DAV clients that know nothing about SVN.
Currently, we have no way of separating a SVN client from a generic DAV
client. In order to fix the DAV clients that dislike our XML we'd need
to be sure to encode for them. However, if we encode properties for
them we'd also be encoding for the old SVN clients that don't know
anything about encoding of properties.
In the past you've said that would be okay, they'd just get a property
name that is different. But this is a compatability breakage. If
talking to a 1.2 SVN DAV server makes svk:foo show up as some other name
then existing SVK clients will break due to not seeing their property
names. This would force all SVK users to upgrade to newer versions of
SVK (or use a newer version of the bindings that know about the
encoding) because the server was upgraded.
As a result you can't fix the encoding problem for the only people it is
creating a problem for (a small minority at that), the DAV clients.
Without breaking our compatability with old SVN clients (a much larger
group).
Given that very few people have run into this issue. I think we have
much more important things to worry about than this. Until 2.0 I think
our only course of action is to discourage people from using colons in
property names. Once 2.0 comes along we can break client
interoperability and start encoding property names as you suggest.
--
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 Mon Oct 18 21:13:58 2004