ISconf4 Development Plan
This page is becoming deprecated; see http://trac.t7a.org/isconf/roadmap and http://trac.t7a.org/isconf/report/3 for latest information.
The Python code needs a few days of my time, solid, to put a first version together. The planning's been done for a while -- essentially what I need to do is sit down with two 'vi' sessions open side-by-side, translating the Perl into Python while getting rid of the plugins and associated internal API cruftiness, and adding more intelligence to the network code.
More details of what needs to be done during the rewrite:
No plugins. When I wrote this I was trying to implement all of the subcommands as plugins that are standalone executables, including 'snap' and 'exec' themselves, so that people could write extensions in any language easily. I finally realized that makes it extremely tricky to upgrade isconf itself, especially if there are file-format changes, because each plugin is an atomic lower-level prereq -- duh, Turing equivalence again. So no plugins, no extensions -- if people want to extend they'll need to do it with wrappers instead, in good UNIX tradition.
I've really been lusting after (at least) two implementations -- one in Perl, the other in Python, regression test the two against each other... The code's small enough that I think we can get away with maintaining both. It would settle the language question, and might even provide a nice rosetta stone to compare between the two. I tend to use Python myself for large projects these days (wasn't true a year ago), which is why I am planning to do the Python version first. This also opens the door to a C implementation if anyone wants to tackle it, for instance.
Multiple implementations means that design docs *will* be needed -- wire protocols and file formats, mostly.
I started realizing a few months ago that there is a horizontal slice that should be done, would not cause prereq problems, and would actually solve some. Right now v4 runs twice -- once as a long-running daemon to do the p2p file serving, and again from rc or command line to do the actual work. The p2p code really ought to be split off as a separate project, an application-layer "Infrastructure Filesystem". (I don't mean mountable -- you talk to it via an API.) This would then be able to serve as a generic place to store things in addition to what ISconf uses it for; a storage place for large or small blobs, with no single point of failure. Think backups or install images... It would also reduce the amount of code that needs to run as root.
I need to finish getting the roadmap page set up (no dates, wrong order), but in general what I'm thinking of doing is rewriting this code from scratch while translating it to Python, but doing so in a directory tree that looks something like:
I'm thinking the right way for isconf to talk to isfs is via a UNIX domain socket; haven't decided whether the message layer (ismq) should be a second daemon or just a library imported by isfs.
An isconfd daemon might also be needed -- trying to keep the daemon count down, but at the same time it might be needed for privilege separation (isconf command line should really not need root uid, should work like sudo instead... might have to push this off 'till later though).
isconf4/python/ismq isconf4/python/isfs isconf4/python/isconf
A second implementation in Perl would then look like:
isconf4/perl/ismq isconf4/perl/isfs isconf4/perl/isconf
And the common test suites would be in:
isconf4/tests
