Hi,
There is a lot to say for this development diary #4 !
Perl module: Slackware::Slackget vs slackget10 :
First of all, the Perl part of the project (currently the biggest part). As you
may all know now : the slack-get Perl module is now listed in the
official Perl
Module list on
CPAN in the Operating
System Interface category. And for this big promotion the module changed its
name from slackget10 to
Slackware::Slackget.
If some of you still wondered : slackget10 is officially abandoned, and today,
completely outdated.
I added a lot of features to this module like the stackable backends. I also
released on
CPAN a debug module which add
the support for a debug:// network protocol. This is a totally fake protocol
which help development by outputing loads of informations on the standard
output. The module name is
Slackware::Slackget::Network::Connection::DEBUG. It's not a part of the
Slackware::Slackget distribution, it's even not in the SVN trunk but in
branch/perl-modules.
One of the big improvement of the Slackware::Slackget module is its test suite
: the latest release on CPAN (0.14) haven't encounter even 1 fail !
I also tried a lot to make the module platform independent, and more generic. I
have rewrite lots of code in order to take all the interdependent code out of
the modules. It's now partially done and the next module which will feel my
scalpel is Slackware::Slackget::PkgTools... I saw some horrible things inside
of this one !
The slack-get suite programs : sg_daemon and slack-get :
Everything have changed ! Beginning with slack-get : this program wasn't
available 2 weeks ago. It's a command line client for the sg_daemon it allow
you to query the daemon. At the moment I write this development diary (svn
revision 110) you can perform the following actions with slack-get : search a
package (based on it's name, or anything in the description of this package),
ask the daemon to rebuild the installed packages cache, ask the daemon to
reload it's media list, ask the daemon to rebuild the update list. Well... now
it only lack the possibility to install, upgrade and remove packages to be
released... I'm already on the remove part (the easiest ^^).
Let's show you some search request performed on a cache which contains the
official
Slackware current repository,
Linuxpackages repository and my own
perl-modules repository (totally outdated) :
This is a big improvement since it actually do something... You may wonder how
it is possible for me to implements 3 or 4 possible actions (features) for
slack-get and have wait for so long before doing it. In fact it's now very easy
and quick to add features to sg_daemon and slack-get because the base
architecture is done coding (and well designed :D).
From now on, the remaining features I will include before releasing a first
version (without any GUI but with the CLI client) are :
- install package
- upgrade package
- remove package
- run background for the daemon
Once it'll be done I will bundle it and release the 1.0.0-alpha2 version.
Obviously, it will be a testing version.
In the real coding side, the last SVN revision of sg_daemon include tons of
improvements like : automatic message formating, a first version of the backend
stack negotiation system (between the daemon and the client), a real and simple
network protocol, a powerfull and working base architecture and a bullet proof
internal communication ! (with that if I don't attract some geek devs I don't
know how to do it
).
The next big part of the work will be the implementation of collaborative part.
But fortunately, a huge amount of this code was already wrote in
slack-get-1.0.0-alpha1. To give you an example, all the code related to the
master/slave mechanism is already written and slack-getd is able to work with
many other daemons withtout to much pain in the configuration side (assuming
you talk XML...).
But in addition to the existing code (that I will still need to port to the new
event-based architecture), I want to add an "auto discover" feature to allow
many sg_daemon(s) to work together without any configuration or human
supervision. I want the daemons able to elect a master, change their mode
between master and slave, and many other distributed stuffs like that, based on
some simple rules (what's the sysload, the average sysload, etc.) in total
autonomy (if the sysadmin allow it !).
In addition to all of this development, I will publish a debug backend for
Slackware::Slackget::Network to allow developers to track the state of a
network message during the encoding and decoding process.
Some news from the GUI point :
I made a graphical interface to get the list of official Slackware mirrors
(from the "Get Slack" page of the official website). It's still not finished
(it cannot update the medias.xml file yet), but it's already working to get the
list and writting it down to the hard disk. I think this dialog will be part of
the final slack-get GUI.
And since it's the first screenshot I can show, here it is :
Well... nothing to climb to the roof but it's a beginning
All the testing GUI are available from the SVN branch : branch/gui_test.
The GUI is the next main development priority after getting the daemon
working.
I think I'm done with this week (and a half...) diary, I'll keep you informed
!
Cya
Arnaud Dupuis.
