[darcs-devel] status of libdarcs?

[John Clayton]

David, thanks for the thoughtful reply, you've obviously spent some  
time considering this and I appreciate that.

I guess I considered myself in category 1 prior to reading this—mostly  
seeking performance gains and non-reliance on a separate install—but  
now you've got me intrigued about the possibilities of category 3. I  
like that there would be advantages to darcs as well, but it also  
obviously means maintaining a much richer set of interfaces in  
libdarcs along with the additional work to add the capabilities to  
darcs.

I wonder, too, if one really wants category 1 functionality if it  
wouldn't be better to pursue a more robust bridge. With Objective-C on  
the Mac, for example, there are two-way bridges for Ruby, Python and  
others. I don't know about the feasibility of extending HOC to bridge  
in the other direction (or the feasibility of a Obj-C -> Haskell  
bridge in general), maybe someone else does. And, since darcs'  
interface pretty much is its CLI, your point about the actual benefits  
of this kind of thing still applies.

I'll have to think some more about this. Is there much interest in  
doing category 3 amongst darcs devs?




>
>
> 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
> _______________________________________________
> darcs-devel mailing list
> darcs-devel at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-devel/attachments/20080328/f288da9d/attachment.htm