On Fri, Mar 16, 2007 at 07:53:06PM CET, Nicolas Pitre wrote:
quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html