No objections here so I marked the roadmap item "Deferred" and green in
r1135058.
- Julian
On Fri, 2011-06-10 at 11:48 -0400, C. Michael Pilato wrote:
> On 06/10/2011 11:38 AM, Hyrum K Wright wrote:
> > On Fri, Jun 10, 2011 at 10:33 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> >> On 06/10/2011 07:39 AM, Daniel Shahaf wrote:
> >>> Julian Foad wrote on Fri, Jun 10, 2011 at 11:17:11 +0100:
> >>>> The consensus seemed to be [1] that we can add/remove/change private
> >>>> APIs during the 1.7.x series,
> >>>
> >>> Indeed that's the consensus I have sensed. I am not sure if we include
> >>> the svn* clients in this "upgrade en bloc" group, but Philip's recent
> >>> work on "1.6 client, 1.7 libraries" does highlight one reason for
> >>> wanting to minimize the use of private APIs in the svn* tools.
> >>
> >> I would be in favor of a policy that explicitly disallows our binaries from
> >> using private libraries. I believe it would serve to force us to think a
> >> bit more globally in terms of what would be useful to expose for the benefit
> >> of other clients.
> >
> > Certainly, but some class of APIs deserves to be private, in my
> > opinion. Our SQLite wrappers, for instance, are used throughout
> > Subversion, but have no business being exposed outside of it. Nobody
> > needs to use them, and exposing them would cause an unneeded
> > maintenance burden in the future.
>
> Sure. I'm not opposed to private APIs. Far from it! But if we're in a
> situation where the code in *"subversion/svn/"* needs to be calling directly
> into our SQLite wrappers, chances are good that we've royally failed in our
> API design, wouldn't you say?
>
> I should clarify my previous statement though. There are some private APIs
> that exist solely for code shared between our command-line clients.
> svn_opt_private.h, svn_cmdline_private.h, etc. I certainly have no
> objection to our command-line clients using that code. But I'm leery of any
> use of svn_wc_private.h, svn_client_private.h, etc. in those tools. Those
> could be red flags for API design failures.
>
> So, in light of the above, I recognize that such a policy statement wouldn't
> be quite as easily worded. So much for "easy".
Received on 2011-06-13 10:35:45 CEST