On Wed, Nov 02, 2005 at 11:50:09PM +0100, Daniel Lutz wrote:
> So, there are already at least 3 projects working on a GUI for darcs
> (mine is based on C++/Qt) :-)
> -> this is a good sign!
:)
> In my opinion the main problem is the inherent interactivity of darcs,
> not to protocol/formatting of input and output.
Indeed... although for some uses (simple repo browsers) this isn't a
problem, and it would be nice to make those simpler applications easier to
build. e.g. if I want a cron job that emails me whenever there are four
new patches in the repository by authors in other research groups that
modify a particular file, it would be nice to be able to write that without
calling darcs interactively. One could extend darcs query to support
arbitrarily complex queries, but I think it would be more flexible to just
allow other programs to easily access all the repository contents.
> I think it should be possible to extend darcs, so that it runs fully
> non-interactively through the normal command-line interface.
>
> For doing this it would probably be necessary to split some darcs command
> into smaller parts. For example: A darcs command which outputs some
> information and needs a decision from the user (based on these
> informations) could be split into
> - a command for querying the necessary information
> - a command (with arguments based on the gathered information) for
> performing an action without need for user decisions A locking mechanism
> (as discussed some time ago) could help here to keep the repository
> unchanged between these commands.
The trouble is that for a separate-invocation scheme to support the full
breadth of darcs feedback, you'd require O(N^2) information when you query
the necesary information. A GUI pull or push would need to find out all
patch dependencies, which is O(N^2) information, and is pretty awkward to
output--plus this is information that darcs doesn't ever calculate itself,
so it requires more work on the darcs side of things. Admittedly, it would
be wonderful if we could figure out a way to display dependencies to the
user, but I'd hate to require that emacs read such a graph just to let the
user select a few patches interactively (where the interactiveness would be
only between the user and emacs). Writing a program to script darcs should
be less awkward than writing darcs itself.
I favor interactive programatic use of darcs--it's just more flexible and
efficient, since you only need to compute dependencies relevant to user
requests (e.g. if user selects a patch, you will want to automatically
select all patches that it depends on). The approach I favor (and I also
favor making multiple options available for calling darcs from an external
program) is to extend the existing interactive mode to output patch numbers
(just counting from 1 up), and to accept numbered commands, e.g. something
like 11y, to say "yes to patch #11, even if I'm not currently viewing patch
#11, or 11v to view patch #11. I suspect that with a few well-chosen
commands, writing an interface using a bidirectional pipe will be pretty
simple. We may need a mode (chosen by a command-line flag) that makes the
output a bit easier to parse.
Two very real advantages of this approach are that
(a) The existing interface benefits from the improvements. With only a
little care, I think the extended interactive commands will be just
as useful to humans as they are to scripts and programs that call
darcs.
(b) The scripting interface will be feature-complete, meaning it will
support all features supported by the human interface. This is
important in that it's not just true when the scripting interface is
complete, but will continue to be true as new features are added to
either interface.
The main downside is that you'd like the machine interface to be completely
frozen, but might want the freedom to update the human interface. The
resolution of this is that you really *don't* want to modify the human
input interface, since we're really less flexible than computers, and are
likely to continue hitting the same keys we're accustomed to. As far as
the output interface goes, as mentioned above, I think a slightly modified
output for the computers is a good idea--but it should still be
human-readable, so we can easily test the machine-interface as interactive
humans.
Note that I do like the idea of having a darcs lock command to lock the
repository while you work on it with multiple invocations, I just don't see
this as an ideal interface. I also like the idea of a C library, but I
see a C library as being desirable primarily because it would be easy to
use, not because it would allow us to export all of darcs' features. A C
library for browsing repositories could have quite a simple interface, and
could be much easier to use than calling darcs with command-line
arguments.
XDR or XML-RPC sound intimidating to me, and seem like very big sticks with
which to whack a very small problem--input to darcs. XML output from darcs
makes tons of sense, but I'd prefer to keep input to darcs much simpler.
--
David Roundy
http://www.darcs.net
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
