monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] New project: libmtn


From: Ingo Maindorfer
Subject: Re: [Monotone-devel] New project: libmtn
Date: Fri, 30 Jun 2006 11:08:49 +0200
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

Hi there!

<snip>
>> - one library - many frontends (for example, GUIs or bindings for
>>   other langs)
>
> Right.  Our strategy to allow this has been the "automate" stuff.  I
> understand why people want a comprehensive library instead, and are
> frustrated by not having it, but, the "automate" approach has some
> important benefits:
>   -- because it is incremental, we don't have to stop everything, go
>      off in a cave, and try to make it work.  The test suite always
>      passes.  Big-bang development is _so_ hard to pull off.
>   -- because it is incremental, we always are working against real use
>      cases.  We don't have to guess what people need, like you have to
>      when you design a whole API before using any of it.  I think of
>      this as another XP-style approach; our experience has been that
>      while this can be frustrating, it's the only way of designing
>      APIs that actually work.
>   -- It is actually more universal than a C library API -- it is hard
>      to access a C API from the shell, for example.  It is _certainly_
>      more universal than another other sort of API (e.g., C++ or Lua).
>
> Then, as we improve the interface and learn what's useful, and we keep
> refactoring the code to reduce duplication, we can
>

_I_ really like the automate interface! Try to compile a program that uses the svn-lib. So many dependencies... Its horrible!
With automate I only write a parser and I'm done.
But the automate interface isn't complete, but I saw that some guys form SOC start to work in that area.

Best Regards,

Ingo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]