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".
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-06-10 17:48:55 CEST