On 17.02.2011 14:12, Stefan Sperling wrote:
> 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.
s/client/repos/g
s/WC/fs/g
s/working copy/versioned filesystem/g
repeat
:)
With a sane, useful public WC API you can at least think about plugging
different WC backends ... someday. Same goes for the repos/fs separation.
-- Brane
Received on 2011-02-17 14:18:01 CET