On Thu, Feb 17, 2011 at 02:17:16PM +0100, Branko Čibej wrote: > 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.
I'd say doing this now is premature optimisation. Especially because wc-ng isn't done yet and we can expect new APIs to appear or existing APIs to change, even during the 1.7->1.8 cycle. When someone comes along and writes a new backend (which is possible since the layers are still cleanly separated even though the API is private), and that backend is likely to be maintained separately so it needs a stable API, then we can do it. Before then, I see little point in the churn involved in reving WC APIs whenever we find a mistake in them. At the backend, separate implementations already exist (fsfs, bdb, bigtable), one of which is maintained by a third party. So maintaining the existing public API there is worth it. And how can we know that the public API we design now is suitable for new kinds of WC backends people would want to write, until such a backend exists? Google ran into problems with assumptions the FS API was making and had to work around them: http://svn.haxx.se/dev/archive-2010-03/0735.shtml