Enforce canonical paths in client-server protocol? [was: svn commit: r12738 - in trunk/subversion: include libsvn_subr mod_dav_svn]

[Julian Foad <ju...@btopenworld.com>]

Greg Hudson wrote:
> On Sat, 2005-01-15 at 14:32, Julian Foad wrote:
> 
>>>>An advantage of being strict is that it leaves room for us to extend the syntax
>>>>in future by assigning meanings to paths that are currently non-canonical.  For
>>>>example, we might one day want to assign a meaning to the double-slash, as in
>>>>current discussions about svn:external.  If we allow that now as being just a
>>>>sloppy equivalent of a single slash, then we shut that door.
>>>
>>>This doesn't work, since the command line client canonicalizes its
>>>arguments.
>>
>>This does work, since the client software that would talk this extended 
>>protocol would not be today's client.  I'm talking about future extensions to 
>>the client-server protocol which would involve modifying both the client and 
>>the server.
> 
> I guess it depends on whether we're more worried about changing the
> protocol to break a non-conformant client, or changing the whole system
> to break a script or other tool which passes non-canonicalized paths to
> the command-line client.

Sorry, I don't understand that sentence at all; for as start, what does "it" 
refer to?

The main thrust of this thread was discussing whether to require that paths 
received by the server are canonical.  Enforcing this would break 
non-conforming clients, and it's not clear whether that would be good or bad in 
the long run.  In any case, I wouldn't describe that as "changing" the 
protocol, just enforcing the current definition, but that depends on whether 
you regard the specification or the implementation as definitive.

Then you talk about changing the whole system and breaking things.  If you are 
referring to my suggestion of extending the client-server protocol in future, 
then you misunderstood: I was suggesting the possibility of extending it in a 
backward-compatible way, such that all today's usage would remain the same but 
additional features would be available (with some new command-line syntax or 
other user interface to invoke them).

Whether a tool passes non-canonicalized paths to the command-line client need 
not affect whether the client passes non-canonicalized paths to the server: 
that's under our control.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org