On Fri, Mar 16, 2007 at 07:53:06PM CET, Nicolas Pitre wrote: > A good way to define the lib API needs then might be expressed as > follows: > > Each existing plumbing commands must be turned into the minimal > implementation required to interact with the libgit public API and > display results. > > In other words, the public libgit API should provide the same > functionality as existing plumbing commands such that those existing > commands will only need the necessary code to bridge the C interface > with the existing command line interface. I think this is good definition if interpreted well - that is, git-log library equivalent shouldn't spew out textual output but provide interface to retrieve revision information in easy-to-use format. > Then, of course, there is the matter of reentrancy. But that's still a > minor API detail even if it is not a trivial issue implementation wise. > But the API must be right as this is what we'll be stuck with even if > the implementation may change. And as far as an API definition is > needed I think that it should reflect the current plumbing which is > actually the real API that grew naturally and has been proven useful. Well what you said about reentrancy is that "it's minor API detail but even minor API details must be right because we will be stuck with them". And I don't think it's minor at all either. :-) Also, even if the implementation won't be completely re-entrant initially, the question of re-entrancy is something we should decide since it still affects the scope of the librarification work. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html