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
