Association Subscribers Manager and Open source stuffs

To content | To menu | To search

Tag - slack-get

Entries feed - Comments feed

Monday 26 November 2007

slack-get development diary #3

Hi,

I was a bit lazy about blogging the slack-get development progression... Me bad, please accept my deepest apologies.
In the other hand, where do you think I spent all the time I didn't on blog ? Yes, you are right : playing SSX Blur on my Wii :)
More seriously, I made some nice improvements in sg_daemon :
  • The file downloading code is now working and use a lot POE. If you checkout the code on Sourceforge's SVN and try out sg_daemon you will see that it is downloading all files to build the updates cache ! I'm quite happy to have this functionality working. Although it's not perfect and I'll make the slackget10::Network::Connection* drivers using the POE way of passing parameters. This will become very handy when I will update the drivers to a trully POE based architecture.
  • The other big progress is about the network protocol. I think that I finally managed to define the needs of slack-get . The keys points are : flexibility and powerfullness. The XML based protocol I defined should meet those requirements. So I defined a base data structure that all network messages must respect, and after that I defined a way to serialize those data. So basically you just need the right serialization component to change the way sg_daemon and slack-get client talks. For the moment I will only develop the XML one but, in order to make easy the creation of other components, when a client connects to sg_daemon a quick handshake is made (sg_daemon send a message with the protocol version, client send a message with its protocol version and his supported serialisation method.
  • Following the move slackget10::Network.pm was almost entirely rewrote to only format the network messages. A new class appeared : slackget10::Network::Message wich is an abstraction of a network message (unbelievable isn't it ?), an object of this type must now be give as parameter to all sg10::Network methods. Those changes are all due to the redefinition of the network protocol and to the rewriting of sg_daemon.
Last but not least : I promise to be more active on this blog ;-)

See ya next time !

Arnaud Dupuis

Sunday 11 November 2007

New slackget10 Perl Module release - version 0.11

Hi,

Well.. I changed so much slackget10::Network::Connection* modules that I made a release of the whole module on CPAN !
This release features :
  • Dynamic driver loading. As explained in another post I made the driver loading code completly dynamic. From now on, you just have a slackget10::Network::Connection::<PROTOCOL>.pm module to add support for <protocol>:// protocol to slackget10::Network::Connection.pm.
  • New slackget10::Network::Connection API. Loads of things have changed in the API of this class. First it's now event driven and it means you have to pass a InlineStates => {} parameter to the constructor. Then the old construction behavior (with only one parameter) is now deprecated and unsupported. Please have a look at the documentation for more information about this.
  • New slackget10::Network::Connection::*.pm API. It's now way easier to create a protocol driver ! You just have to create a module with the 3 followings methods defined inside : __test_server(), __get_file(), __fetch_file(). They'll be called by slackget10::Network::Connection.pm wich will take care of everything (like event throwing).
This class is now fully usable out of the box in other programs than just slack-get, and that was one of the goal of the slackget10 module !
I'll made a HOWTO on the wiki to explain how to create a driver.

Good day

Arnaud Dupuis

Saturday 10 November 2007

Week end planning

Hi ,

I'm working a lot on slack-get this week end ! Today's morning was concentrated on slackget10::Network::Connection modifications. I made quite a lot of them. I made two major changes in the module architecture :

  1. I made the protocol driver's loading completly dynamic (no more static, hardcoded hash table to track authorized protocols)
  2. I changed all drivers (slackget10::Network::Connection::*) and made them independents from the slackget10::Config. The "config" parameter is not required anymore. In place of this option you have to give the "download_directory".
The other thing I planned for the week end is to polish my skills with Qt4. I'll try to make the configuration widget for the GUI this week end... even if I can't promise anything.

I also updates the Wiki by creating some API documentation pages.

Let's keep the pace !

Arnaud Dupuis

Tuesday 6 November 2007

slack-get development diary #2

Hi,


First let me tell you some things about me : I've got a new job recently. I'm now working in a IT consulting company in their Open Source business unit. That's great !

I also marry my fiancée in June... So you can tell that I have less time to code ;-)

That was for the explanation why I haven't code a lot this week :)

But the slack-get development is still moving quite nicely, even if I had loads of problems this week. I focused on turning all the network handling code in sg_daemon POE compliant. So I looked at a POE Component (PoCo) wich implements the HTTP protocol.. Great the is one who manage parallel downloads !! I tried it and it is just what I need. So I began to search the same things but for other protocols sg_daemon support... and here are the problems.

I found nothing for the FILE protocol and the PoCo for FTP is still young and do not provide the same API than PoCo::Client::HTTP. So I ended to reverse the changes I already made to slackget10::Network::Connection::HTTP and decided to change the API to emulate the POE way of doing things. So the slackget10::Network::Connection object must, now, be constructed with an argument InlineState => {}which contains 3 events : progress, download_finished, and download_error. You have to associates a handler to each of this events.

Talking about this class, the internal architecture have changed and it is now way easier to add drivers for slackget10::Network::Connection. You just have to create a class wich implements some methods. It will be the feature highlights of the week.

I have not much to say considering that all my family stuff for my weddings and all the problems I met with the "POE-ification" of the network code slowed me down a lot.

Let's hope for next week :-)

Enjoy !

Arnaud Dupuis

Tuesday 30 October 2007

slack-get feature highlights #1 : managing the install medias

Hi !

Today I'm introducing a new kind of post : the slack-get functionality highlights. What is that ? Well once a week (or more often maybe) I will introduce and explain a specific functionality of slack-get.
It can be in sg_daemon, or slack-get tools (CLI or GUI). It can also be some nice features of one of the slack-get libraries (slackget10 Perl module or the upcoming C++ one).

Enough introduction ! Today's highlight is about the media management system. Before everything, please note that all the examples in this diary will work on all slack-get version >= 1.0.0_pre-alpha1

How do slack-get manage its media and how the daemon choose to download a package from a server or another ? This is indeed a good question because there is very few documentation about this feature.... my bad :(
So.. slack-get use a configuration file called medias.xml where all medias are listed. This file is a XML one (as suggested by its extension...), and look like that :
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<medialist>
    <media id="media1">
       // lets forget this part for now
    </media>
    <media id="media2">
       // ...
    </media>
</medialist>



Quite easy to understand isn't it ? there is a media list which contains a list of media... fair enough :)
Now what about the <media></media> entity ? It's basically THE basic entity for all media you want to use as an install source.
As I write this, you can have 3 types of media :
  • http ones. For all repositories you access via the http protocol ;
  • ftp ones. For... yes : all the repositories you can access via the ftp protocol ;
  • file ones. That's the general one. You can use it for installing Slackware packages from your Slackware DVD, from a NFS drive or any other repository which can be seen as "local filesystem" by your system.
The structure of the XML entity <media></media> look like that :
<media id="a_media_id">
    <files>
        <filelist>FILELIST.TXT</filelist>
        <checksums>CHECKSUMS.md5</checksums>
        <packages>PACKAGES.TXT.gz</packages>
    </files>
    <update-repository>
        <faster><!-- an URL --></faster>
       <fast>
          <li><!-- an URL --></li>
          <li><!-- another URL --></li>
       </fast>
       <slow>
          <li><!-- an URL --></li>
          <li><!-- another URL --></li>
       </slow>
    </update-repository>
    <description>The description of this media.</description>
    <web-link>http://www.mysite.org</web-site>
</media>


The <files></files> entity gives the name of the files which actually contains the wanted informations. there is 3 informations wanted :
  1. the list of the repository files ( usually in the FILELIST.TXT file ) ;
  2. the list of the files checksums ( usually in the CHECKSUMS.md5 file ) ;
  3. the detailled list of packages ( usually in the PACKAGES.txt file ).
the slackget10 Perl module compile all those informations in a single file ( called installed.xml, we will discuss about it in another "slack-get functionality highlights" issue ).
You can say here if you prefer to download the compressed version if exists and if the repository is not really standard (file name in lower case for example) you also have more flexibility here.
I got emails from a bunch of peoples who even used the old slack-get daemon (slack-getd) to install red hat packages ! Which means one thing : you can do more than I coded with slack-get :D
Actually, it's not hard to modify the initial way-of-doing-things of slack-get, you just have to replace some of the Perl modules.

Let's see a simple example : adding the Slackware 12.0 DVD to the media list.
First open the medias.xml file with your favorite editor, then add the following :
    <media id="SlackDvd12.0">
        <files>
            <filelist>FILELIST.TXT</filelist>
            <checksums>CHECKSUMS.md5</checksums>
            <packages>PACKAGES.TXT</packages>
        </files>
        <update-repository>
            <faster>file:///mnt/cdrom/</faster>
        </update-repository>
        <description>The official 12.0 cd-rom directory.</description>
    </media>

The first thing you can note is that we didn't used all the possible XML entity in this example. Indeed all fields are not mandatories. The only mandatories "fields" (attribute or tag) are :
  • id : the media id attribute ;
  • the <update-repository></update-repository> tag ;
  • the <faster></faster> tag.
So we added a new media, its id is "SlackDvd12.0", it use the standard files (so we can simplify this entry and remove the <files></files> section), and the only repository we have is in the /mnt/cdrom/ and have a small description.
We can simplify this media section (without loosing any informations), like that :
    <media id="SlackDvd12.0">
        <update-repository>
            <faster>file:///mnt/cdrom/</faster>
        </update-repository>
        <description>The official 12.0 cd-rom directory.</description>
    </media>


This example, is simple and quickly added, let's have a look at a more complete example, by adding the LinuxPackages repository to our medias list :
    <media id="linuxpackages">
        <files>
            <filelist>FILELIST.TXT</filelist>
            <checksums>CHECKSUMS.md5.gz</checksums>
            <packages>PACKAGES.TXT.gz</packages>
        </files>
        <update-repository>
            <faster>http://opensys.linuxpackages.net/Slackware-11.0/</faster>
            <fast>
                <li>http://www.nymphomatic.org/mirror/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.inode.at/Slackware-12.0/</li>
                <li>http://ftp.scarlet.be/pub/linuxpackages/Slackware-12.0/</li>
                <li>http://www2.linuxpackages.net/packages/Slackware-12.0/</li>
                <li>http://mirror.etf.bg.ac.yu/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.slackwaresupport.com/Slackware-12.0/</li>
            </fast>
            <slow>
                <li>ftp://linuxpackages.inode.at/Slackware-12.0/</li>
                <li>ftp://ftp.scarlet.be/pub/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.cgucccc.org/Slackware-12.0/</li>
                <li>ftp://ftp3.linuxpackages.net/pub/Slackware-12.0/</li>
                <li>ftp://mirror.etf.bg.ac.yu/linuxpackages/Slackware-12.0/</li>
                <li>ftp://ftp.slackware.hu/linuxpackages/Slackware-12.0/</li>
                <li>ftp://opensys.linuxpackages.net/pub/Slackware-12.0/</li>
                <li>ftp://ftp.nymphomatic.org/linuxpackages/Slackware-12.0/</li>
            </slow>
        </update-repository>
        <description>Slackware resources to help install and configure the Linux slackware distribution, Email list, Discussion Board, Howtos, Contributed packages, and much more</description>
        <web-link>http://www.linuxpackages.net</web-link>
    </media>


Here we specify compressed files in the <files></files> section. This is possible because the slackget10::File class can load both of compressed and uncompressed files.
Then we have a list of repositories. The <faster></faster> one is like your preferred mirror, it will always be used unless it is not reachable. If it's not, servers in the <fast></fast> section are tried, then come the ones in the <slow></slow> section.
As you can see we have mixed type of mirrors : some are HTTP ones while other are FTP ones. That is not a problem, you can mix sources of all kinds. The only limitation is that slack-get must have a driver for the specified protocol (for the moment you can use only, http://, ftp:// and file://).
You can also see that we have set a web site for this media. This information is use in many way, for example in the search page of the slack-get site, or in the GUI to provide a link to the repository maintener site.

In real world, slack-get can test all the repositories and classify them by their answer time. Like in many other fields, I tried to make the slack-get's parts as clever as possible and do the right thing with the right informations. I hope it works ;-)

Now for the unreleased things and the unbelievably new informations : I will add the support of variables in repository URLs... this will allow you to write things like that in your medias.xml :
<update-repository param="$SLACKWARE_VERSION=12.0">
    <faster>http://opensys.linuxpackages.net/Slackware-$SLACKWARE_VERSION/</faster>
</update-repository>


Nice isn't it ? I'm still not sure about the final shape of this feature but I think it'll be like I just showed you.

To conclude, you are now more informed on the media management system of slack-get and you can easily manually add new repositories to your medias.xml file.
In the next version of the GUI you will be able to edit this file with a nice window.
I hope this article helped you to better understand some of the slack-get's black magic :-)
Please, feel free to react, comment and propose improvements.

Arnaud Dupuis

Saturday 27 October 2007

slack-get development diary #1

Hi !

I've got a lot to say today !
First of all I was surprised by the number of failed test in my last release of the slackget10 Perl module. After some work on this, and with the great help of David Cantrell, we managed to find to work out the problem.
It is in the test suite of XML::Simple (used by slackget10::Base and other slackget10::* classes) : if XML::Parser failed to install the XML::Simple's test suite do not chain fail, and the installation is not done well, but it's done.
So if you try to use XML::Simple with the directive :
$XML::Simple::PREFERRED_PARSER='XML::Parser';
slackget10::Base just crash. David submitted a patch which is very simple but also very efficient :
eval 'use XML::Parser';
if($@) {
    warn("XML::Parser is not installed. XML processing operations will be very slow.\n");
} else {
    $XML::Simple::PREFERRED_PARSER='XML::Parser' ;
}


It fixed the problem, and I have integrated it directly to the trunk of slack-get SVN repository.

The second point is the slack-get communication protocol draft. Things are going well, I think I finished to determine at least 70% of the communication needs.
If you are willing to give me an advice on this draft do not hesitate ! Go checkout the SVN version and have a look in the trunk/devel/ directory.

About sg_daemon now : I've got the internal scheduler working ! yeehaa !
I've finish the porting of the "installed packages list building" functionality  and it's now working with the internal scheduler of sg_daemon.
The great thing is : that was the hardest part :)
Porting the other functionalities will be easy... or not... indeed some internal functions of sg_daemon are not adapted to the POE architecture and will take some time to port.

Last but not least, I've come with a new icon for slack-get, feel free to give your opinion :

Wednesday 24 October 2007

new release of the slack-get Perl Module - slackget10-0.10

Hi all !


After doubt and interrogation, even after I though to dismiss the slack-et project it couldn't be helped... I enjoy developing this tool !
So be it. Here is the latest release of the slack-get Perl Module. Tons of thing are new since there was a not-released version...
This release main features are :
  • loads of bugfixes (starting with the test suite)
  • removed unused modules
  • removed deprecated modules
Well a lot of things !

I'm now working on the slack-get communication protocol. This protocol is full XML based and have to be well designed to support all situation of usage.
It also have to be bulletproof and highly error resistant.

By the way the slack-get devel mailing list have open, please find more information on this at Sourceforge , you can also find more informations about slack-get SVN on Sourceforge.

You can find all documentation and source of the new version of slackget10 on CPAN

That's all for the moment.

Good day

Arnaud Dupuis

Saturday 8 September 2007

slack-getd is dead, long live sg_daemon !

It's now official : slack-getd is dead. There is a lot of (good) reasons for me to do so :

  1. The network protocol is not totally unified. Part is plain-text based and part is XML based.
  2. While recoding slack-getd to create a fully event driven daemon I saw some important part of the code which couldn't be moved easily from the old behaviour to the new event based one.
  3. Extending slack-getd possibilities is not that easy to do with the current implementation.
So far I though that if I change the major version number it's for something, and above everything, if I recode everything it's not to harass myself with unmaintainable code !

In the end sg_daemon will include the following features :
  • a fully event driven code
  • a full XML network protocol
  • an easy to maintain and easy to extends code

I do hope to release the first working version soon (within the month). Obviously if the network protocol change it will no longer works with the current GUI.
But I'll try to add some compatibility code, at least for the RC1 version.

All this things obviously change the scheduled release plan, and I'll release more release candidates for the 1.0.0-alpha branch than initially planned.

Arnaud DUPUIS

page 2 of 2 -