[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