On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
> On 17.02.2011 13:39, Julian Foad wrote:
> > Let me point out the background, in case you weren't aware. There has
> > been a general feeling (especially during the WC re-write) that the WC
> > API wasn't well suited to being maintained as a public API and that we
> > should move in the direction of providing a better client-layer public
> > API instead.
>
> I think going that way would be a terrible mistake. By all means make
> the WC API useful on its own.
What's the benefit to API consumers?
An internal client/WC separation makes sense because code is layered
cleanly. But to the outside the entire client lib is already a black box
that can contact a repository and also modify a working copy.
Why have another, smaller, black box sitting next to it that can only
perform a subset of the same tasks? If I wrote a program against these
APIs today I wouldn't readily know which one to use when.
And the less public functions we have, the more agile we can be when
changing internals of libsvn_client and libsvn_wc. So for us, the
benefit of keeping the wc API private is huge, while there's not much
benefit for API consumers if we make it public.
Of course, this implies adding new public API functions at the client
layer if there are things clients want to do that they cannot do
with the current client APIs.
Received on 2011-02-17 14:13:02 CET