[darcs-devel] status of libdarcs?

[David Roundy]

On Thu, Mar 27, 2008 at 10:51:19AM -0700, John Clayton wrote:
> I've only just started to learn Haskell, so bear with me if this  
> sounds stupid ;-)

It doesn't.

> What I was thinking when I heard libdarcs was some kind of library in  
> C that would allow a C-family application to access darcs data  
> structures through some safe interface, or, in a more robust form, an  
> interface that would actually allow one to invoke the darcs operations  
> in the public interface from a C app, though that seems a good bit  
> harder in my mind.  I figured this would require using Haskell's FFI,  
> but don't have a clue beyond that.
> 
> How hare-brained is that idea?

The problem isn't calling haskell from C, that's easy.  The problem is that
you presuppose the existence of a safe interface.  Darcs doesn't have a
safe interface, except for the existing command-line interfaace, so we'd
have to construct a safe interface.

Also related to that is the question of what you think would be more
robust.  The interface for calling darcs is actually quite robust, unless
you're trying to use its interactive interface.  Perhaps what you want is
to avoid issues with users upgrading darcs in a way that breaks your
application?

I guess there are three basic camps of libdarcs advocates, and I don't know
which you fall into:

1. They want to do exactly what can be easily done by calling darcs from
the command-line, but would rather have a function call than an annoying
system call.  i.e. they want an "easy-from-C" way to call darcs, and
nothing more.

  This is appealing to C/C++ programmers and maybe Haskell programmers, but
  has no draw for python, shell, elisp or perl programmers.

2. They want to interact with the darcs interactive layer (e.g. patch
selection), but don't want to mess with pipes and all that.  They don't,
however, want to do anything beyond what darcs is already capable of doing
through its interactive interface.

  This is appealing to C/C++ programmers, Haskell programmers, and also
  appeals to python, elisp or perl programmers, but probably not to shell
  programmers.

3. They want to do things with darcs repositories that darcs doesn't
currently do, such as create graphs of patch dependencies.

  This appeals to pretty much anyone, because by definition it makes new
  things possible.  It also (by definition) means implementing new
  functionality in darcs, not just a new interface.

This is obviously a pretty crude distinction, but it makes a big difference
what category you're talking about when you ask for a libdarcs.  If you're
in category 3, you may need to learn that darcs doesn't in fact implement
all sorts of hidden functionality, and that the existing interface pretty
much covers all that darcs has been programmed to do.  Making it do more
requires more programming, not just a fancy interface.

If you're in category 2, you need to figure out an interface that allows
interaction between your program and darcs.  This interface would need to
be more robust than setting up a couple of pipes, otherwise there's no
point.  You also might think you're in category 2, when you're actually in
category 3.

If you're in category 1, then it'd be pretty easy to write an interface,
but that interface would also do you very little good.  What do you
actually gain by calling darcs("get", "http://foo.bar") instead of calling
system("darcs get http://foo.bar")? All you really gain is:

  (a) You don't rely on the existance of a separate darcs binary.  On linux
  systems this typically doesn't matter, as packagers will ensure that
  folks who use your package also have darcs.  On windows and macos
  systems, maybe it helps, but if you've got an installer, you could
  probably just install darcs.  Also note that for ssh access, you'll rely
  on an external program in any case.

  (b) You're insulated from changes in the command-line interface of
  darcs.  However, you're now subject to changes in the libdarcs API.  If
  you don't trust us to maintain the one, why do you think we'll maintain
  the other, since it seems harder to maintain an API that is equivalent in
  functionality to a set of command-line flags, than to maintain the set of
  flags itself.  True, we have in the past deprecated or removed flags, but
  pretty rarely, and we do try to listen to our users.

  (c) You could avoid parsing the output of darcs.  The catch is that you
  instead have to handle whatever data structures we happen to give you.

I'm can't think of any other advantages of a category 1 libdarcs API.
Advantage (c) of course requires quite a lot more work, since it supposes
that one translates complicated data structures into formats that are
useful in C.  There's a continuum of implementations in Category 1, since
you need not expose all of darcs' functionality in a given libdarcs.
e.g. you might want to only expose push/pull/record for a minimalist
application that just wants to keep track of changes.

So the question becomes, what sort of libdarcs are you talking about, and
why do you want it?
-- 
David Roundy
Department of Physics
Oregon State University