On 06/10/2011 11:38 AM, Hyrum K Wright wrote: > On Fri, Jun 10, 2011 at 10:33 AM, C. Michael Pilato <cmpil...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
