You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2007/03/12 04:54:03 UTC
Re: svn commit: r23760 - in
branches/sparse-directories/subversion: libsvn_ra_svn svnserve
I'm with Peter on this one. I don't see why we should be
second-guessing the future necessity of depth in particular as a
parameter, nor do I think that parameters in general should be made
optional just because they might some day in some unknown way become
obsolete. (I realize in this case it's zero-cost to do so because
backward-compatibility already forces the server to handle the case of
an unspecified depth. But it's conceptually messy, to me, and it's a
bad precedent.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r23760 - in branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Karl Fogel <kf...@red-bean.com>.
plundblad@google.com (Peter Lundblad) writes:
> Greg Hudson writes:
>> I'm with Peter on this one. I don't see why we should be
>> second-guessing the future necessity of depth in particular as a
>> parameter, nor do I think that parameters in general should be made
>> optional just because they might some day in some unknown way become
>> obsolete. (I realize in this case it's zero-cost to do so because
>> backward-compatibility already forces the server to handle the case of
>> an unspecified depth. But it's conceptually messy, to me, and it's a
>> bad precedent.)
>
> Yeah, my intention was to make the protocol easy to understand.
> If you make a parameter optional, you must document its meaning *today*
> (which was depth infinitiy) and then clients start relying on that...
Okay, let's leave it de-tupled.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: svn commit: r23760 - in branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Mar 12, 2007 at 11:15:11AM +0100, Peter Lundblad wrote:
> Malcolm Rowe writes:
> > Specifically, I think the last sentence is probably wrong - if the item
> > isn't optional, it should probably just be standalone, not enclosed
> > in parentheses.
> >
> Agreed. Maybe optionality should not be discussed in this depth here, because
> it is orthogonal to extensibility?
>
I think it's still necessary to discuss it, but only because our
approach for adding new optional parameters differs from that for adding
mandatory parameters.
I did some cleaning up in r23895; let me know if you think it's okay
now.
Regards,
Malcolm
Re: Re: svn commit: r23760 - in branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Peter Lundblad <pl...@google.com>.
Malcolm Rowe writes:
> 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.
> ---
>
> Specifically, I think the last sentence is probably wrong - if the item
> isn't optional, it should probably just be standalone, not enclosed
> in parentheses.
>
Agreed. Maybe optionality should not be discussed in this depth here, because
it is orthogonal to extensibility?
> (How common is 'braces' as a synonym for 'brackets' by the way? It's not
> one I'd come across before).
>
No idea, but I'd say that "braces" is confusing anyway. Personally, I'd
prefer "brackets".
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: svn commit: r23760 - in
branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2007-03-12 at 10:01 +0000, Malcolm Rowe wrote:
> 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.
> ---
>
> Specifically, I think the last sentence is probably wrong - if the item
> isn't optional, it should probably just be standalone, not enclosed
> in parentheses.
Huh, did I write that? Regardless, I agree; the last sentence is wrong,
and it would be clearer if we used a non-optional added parameter as an
example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: svn commit: r23760 - in branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Mar 12, 2007 at 10:34:29AM +0100, Peter Lundblad wrote:
> Yeah, my intention was to make the protocol easy to understand.
> If you make a parameter optional, you must document its meaning *today*
> (which was depth infinitiy) and then clients start relying on that...
>
Based on this conversation, I'm confused as to whether the last section
in libsvn_ra_svn/protocol is correct:
---
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.
---
Specifically, I think the last sentence is probably wrong - if the item
isn't optional, it should probably just be standalone, not enclosed
in parentheses.
(How common is 'braces' as a synonym for 'brackets' by the way? It's not
one I'd come across before).
Regards,
Malcolm
Re:
Re: svn commit: r23760 - in
branches/sparse-directories/subversion: libsvn_ra_svn svnserve
Posted by Peter Lundblad <pl...@google.com>.
Greg Hudson writes:
> I'm with Peter on this one. I don't see why we should be
> second-guessing the future necessity of depth in particular as a
> parameter, nor do I think that parameters in general should be made
> optional just because they might some day in some unknown way become
> obsolete. (I realize in this case it's zero-cost to do so because
> backward-compatibility already forces the server to handle the case of
> an unspecified depth. But it's conceptually messy, to me, and it's a
> bad precedent.)
Yeah, my intention was to make the protocol easy to understand.
If you make a parameter optional, you must document its meaning *today*
(which was depth infinitiy) and then clients start relying on that...
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org