[darcs-users] Darcs Perl Contributors Unite!
Mark Stosberg
mark at summersault.com
Mon Dec 13 00:48:51 UTC 2004
Darcs now has a number of related Perl tools:
- darcs.cgi
- tla2darcs
- cvs2darcs
- darcs2rss
- darcshive
Whoa. They all have names of the same length. Spooky.
Besides being in Perl, they all have some other things in common:
- They all implement their own interface to darcs and its data.
- None of them have any test suite to speak of.
Considering this state of affairs, I think it would save time and energy
in the long run to collaborate on a modularized Perl interface to darcs
and its data.
I expect the outcome would be of the quality of the better modules on
CPAN: It would be well documented, include a substantial test suite, and
have a clear interface.
Once done, Perl projects can focus on their own cool value-added features,
and quit worrying so much about the 'backend' work of talking to darcs.
One interesting additional project that might be become 'easy' because
of this is a GUI desktop tool, written with one of Perl's many
graphics library alternatives (Wx, QT, GTK or Tk).
I propose this general flow for proceeding:
1. Assessment. Inventory all of the darcs interface functions used
so far. Note which one ones are pure Perl and those that call the
darcs binary.
2. High level design. Document the high level class and method names to
use, with the existing functionality requirements as a base. The goal
would be include methods that talk directly to darcs or the repo data.
There would be nothing in the core about CVS, TLA, RSS or CGI
interfaces.
At this level, we should separate out 'pure perl' solutions, with
those that (may always) depend on the darcs binary.
3. Detailed Docs. Once the high level design in agreed upon. flesh out
the details of what the methods will do.
4. Write tests. Write automated tests to cover all the key functionality.
Make sure the tests fail, since the code hasn't been written yet.
5. Write the code. Hopefully the meaty parts of this can refactored
easily from one of the existing implementations.
6. Refactor the existing Perl projects to use the new backend module.
7. On the seventh bullet point, we rest.
I think I can volunteer to help some this. Who else is in?
Mark
--
http://mark.stosberg.com/
More information about the darcs-users
mailing list