Re: svn commit: r21682 - in trunk: subversion/libsvn_ra_svn www

[Daniel Rall <dl...@collab.net>]

On Fri, 29 Sep 2006, Karl Fogel wrote:

> Daniel Rall <dl...@collab.net> writes:
> > On Wed, 27 Sep 2006, kfogel@tigris.org wrote:
> > ....
> >> --- trunk/subversion/libsvn_ra_svn/protocol	(original)
> >> +++ trunk/subversion/libsvn_ra_svn/protocol	Wed Sep 27 12:04:02 2006
> > ...
> >> +4.1. Extending existing commands
> >> +
> >> +Extending an existing command is normally done by indicating that its
> >> +tuple is allowed to end where it currently ends, for backwards
> >> +compatibility, and then tacking on a new, possibly optional, tuple.
> >> +For example, set-path was extended to include lock-tokens like this:
> >> +
> >> +  /* OLD */ set-path:
> >> +    params: ( path:string rev:number start-empty:bool )
> >> +
> >> +  /* NEW */ set-path:
> >> +    params: ( path:string rev:number start-empty:bool ? [ lock-token:string ] )
> >> +
> >> +The "?" says that the outer tuple is allowed to end here, because an
> >> +old client or server wouldn't know to send the new subtuple.  The new
> >> +subtuple appears in square braces because, even in the new protocol,
> >> +the lock-token is still optional (but if there's no lock-token to
> >> +send, then an empty tuple must still be transmitted, so that future
> >> +extensions to this command remain possible).  And if lock-token were
> >> +mandatory in the new protocol, then the braces would be parentheses
> >> +instead.
> >
> > We probably want to indicate that optional arguments (as tuple
> > contents) for *new* commands need not use the "?" character before the
> > "(?x)" sequence, but should use that latter sequence to allow more
> > parameters to easily be added at the end of the command.
> 
> Can you say that in more words?  I'm not quite catching it...

I was suggesting that we say something about declaring optional tuples
for new commands.  However, given this paragraph from the protocol
doc, I no longer think what I was suggesting is necessary:

"For extensibility, implementations must treat a list as matching a
prototype's tuple even if the list contains extra elements.  The extra
elements must be ignored."