You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/12/19 19:32:53 UTC
issue #1648: depth indicator in internal API
Issue #1648 is about anticipating a possible future UI, the --depth
option, by making some internal function interfaces take a tri-state
'depth' enum instead of a bi-state 'recurse' boolean.
Although there are good arguments both ways (see the issue for links),
I think this change should not go into 1.0, for a couple of reasons.
First, we don't know for sure how the --depth option is going to work,
or that we're definitely going to do it at all. Yes, we've discussed
it, but the enhancement has not been spec'd out to the degree it would
be if we were implementing it right now. It feels wrong to make an
anticipatory internal API adjustment for a feature that isn't even
completely designed yet.
Second, even if the --depth option does get implemented in the near
future, and looks exactly as we expect it to, there are strategies for
dealing with the compatibility issues then. We can keep the current
function names as wrappers around new functions that end in "_depth"
or whatever, officially deprecate the old ones, and then in a future
API-changing release, make the final break in the obvious way.
This strategy can be applied to other API changes too, but I think
it's particularly appropriate here, given that the UI feature for
which we're proposing the new API doesn't even exist yet.
So, I'm not planning to vote for #1648. This mail is not a veto, but
I hope it encourages others to not vote for #1648 as well.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1648: depth indicator in internal API
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 19, 2003 at 01:32:53PM -0600, kfogel@collab.net wrote:
>...
> This strategy can be applied to other API changes too, but I think
> it's particularly appropriate here, given that the UI feature for
> which we're proposing the new API doesn't even exist yet.
Yup. I think it is driven from a technology basis ("ooh. that seems
better.") than a desired user feature basis.
A phrase that I learned a *long* time ago applies here:
Just because we *can*, doesn't mean we *should*
IOW, yah... neat tech. Is it really needed? [and how?]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1648: depth indicator in internal API
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 22 December 2003 22:03, C. Michael Pilato wrote:
> [snip]
>
> > On the other hand, if we do anticipate adding this feature, I think
> > replacing the boolean with an enum is pretty trivial, and pretty
> > obviously a key step in the right direction. It could be a
> > two-element enum for now, so we wouldn't be specifying any
> > unimplemented behavior.
>
> This is wise.
I agree with this as well. It's a simple thing that we can do now that may
prevent an API change down the road.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1648: depth indicator in internal API
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> If we're not going to implement such a feature at all, then sure,
> let's punt. If there are any ardent supports of --depth, they should
> speak up as soon as possible.
I don't count myself as an ardent supporter -- our recursive behavior
as it exists today has never gotten in my way. It's mildly annoying
that commit's use of non-recursive is the only place in our codebase
where that means depth=0 (everything else is depth=1). And I
certainly can see merit in the ternery depth state. But do these
necessitate immediately improvement? I doubt it.
> On the other hand, if we do anticipate adding this feature, I think
> replacing the boolean with an enum is pretty trivial, and pretty
> obviously a key step in the right direction. It could be a
> two-element enum for now, so we wouldn't be specifying any
> unimplemented behavior.
This is wise.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1648: depth indicator in internal API
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> What makes these functions "internal?" We would need to change
> libsvn_client as well as libsvn_ra, and neither of those is
> "internal."
Oh, that was just redundant FUD on my part. I meant "functions" as
opposed to "external UI", that's all.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue #1648: depth indicator in internal API
Posted by Greg Hudson <gh...@MIT.EDU>.
> Issue #1648 is about anticipating a possible future UI, the --depth
> option, by making some internal function interfaces take a tri-state
> 'depth' enum instead of a bi-state 'recurse' boolean.
What makes these functions "internal?" We would need to change
libsvn_client as well as libsvn_ra, and neither of those is
"internal."
> First, we don't know for sure how the --depth option is going to
> work, or that we're definitely going to do it at all. Yes, we've
> discussed it, but the enhancement has not been spec'd out to the
> degree it would be if we were implementing it right now. It feels
> wrong to make an anticipatory internal API adjustment for a feature
> that isn't even completely designed yet.
If we're not going to implement such a feature at all, then sure,
let's punt. If there are any ardent supports of --depth, they should
speak up as soon as possible.
On the other hand, if we do anticipate adding this feature, I think
replacing the boolean with an enum is pretty trivial, and pretty
obviously a key step in the right direction. It could be a
two-element enum for now, so we wouldn't be specifying any
unimplemented behavior.
> Second, even if the --depth option does get implemented in the near
> future, and looks exactly as we expect it to, there are strategies
> for dealing with the compatibility issues then. We can keep the
> current function names as wrappers around new functions that end in
> "_depth" or whatever, officially deprecate the old ones, and then in
> a future API-changing release, make the final break in the obvious
> way.
We could; it's just really ugly, and we'd have to keep them around
longer than we think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org