Infinity Perl : slack-get, Perl, Qt, KDE and other Open source stuffs

To content | To menu | To search

Tag - development

Entries feed - Comments feed

Saturday 30 August 2008

slack-get user interface: step 1, how I see the futur

Hi,

as I already said I am currently developping the C++ API of slack-get. I also wrote that I am concentrating on usefull part of the API, skipping the generative parts that are not absolutly required at the moment. So in parallel to this development, I made some tests for the graphical user interface. I came up with the conclusion that there is 2 different way to use slack-get :

  1. Keep a Slackware box up-to-date by installing security fixes and Slackware patches
  2. Keep a box up-to-date, upgrade and install packages (but not patches)
So, considering that I decided to come with 2 different GUI : a dock application to tell users that there is patches available and the full graphical client (like the previous slack-get GUI).
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :


I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.

That's all for today :)

Arnaud Dupuis

Friday 29 August 2008

Release: Slackware::Slackget v0.17

Hi,

A new version of the Slackware::Slackget module was released on CPAN.
This release features the followings changes :
 - lots of fix in order to make all classes of the module SGNC Compliant
 - Slackware::Slackget::GPG have had many methods implemented
 - change the to_string() behavior of the Slackware::Slackget::PackageList, Slackware::Slackget::Package and Slackware::Slackget::List to make them able to generate a Slackware's PACKAGES.TXT (supporting, of course, the slapt-get/swaret format for dependencies).

This module was in a need of a new release since the documentation have been updated a lot (and I personally use CPAN as my API doc reference ^^).

Arnaud Dupuis

Wednesday 27 August 2008

First parts of the C++ API

Hi,

I uploaded on the SVN repository the first part of the slack-get C++ API.

I am coding this one to be as close as possible to the Perl one. So the first two classes uploaded are, of course, Slackget::Package and Slackget::PackageList. As you can see I am using the Slackget:: namespace in order to identify slack-get's classes.

As usual, the documentation and all doxygen needed files are already on the SVN too.

I am focusing on usability and stable features for this C++ API. This means that, in a first time, I will not translate all features. All classes that will fall in those exceptions will be adequatly documented.

My goal with this API is to start coding the graphical user interface as quickly as possible.

Arnaud Dupuis

Wednesday 13 August 2008

slack-get development diary #6

Back from a long silence period, here it is : the 6th opus of the "slack-get development diary" !
There is a lot of new things that I need to talk about !
First the bad news : I saw on CPAN reports that the "fix" I made for Slackware::Slackget to properly test on Solaris OS is not working.
That is a bad thing but... I don't really see the purpose on trying to fix an issue on an OS which is not a Slackware based one and not even a GNU/Linux OS ! The Slackware::Slackget module will never be usefull on this OS, so since I have no Solaris to test I will just forget about it (unless somebody provides me with a patch for this system.

Now for all the good news :
  • slack-get suite (sg_daemon + slack-get) is now able to install, upgrade and remove packages
That's the first point, and I think it's a pretty important one. I fixed all the daemon and the (cli) client to make them able to perform packages operations without any problems.
So from now on, you can start a daemon and do a "slack-get install flightgear" for example :)
That's a very important point but it's nothing worth talking about without the dependencies tracking system.
Talking about that...
  • the dependencies tracking system is now fully functionnal
Woohooo ! This part was certainly one of the most painfull, but I finally manage to get it working the right way.
This part still need to be tested and there is no guarantees, so far, that it is working properly in all cases.
But so far my tests where very promisefull ! I add no problems and for the moment I have not yet discovered any bugs in this feature.
Again, that does not means that I will not uncover bugs later.
  • add support for automatic GPG key import
I added the possibility for the sg_daemon to download and import a GPG key. For the moment it only import Slackware Project's key and it is almost hardcoded but there is no reasons to extend this feature to all medias sooner or later.
This feature works well and is totally automatic : if sg_daemon do not find the Slackware Project's key in the user's GPG keyring, it download it and import it. Nice and easy.
  • add new feature to slack-get (cli client)
I added a new command to slack-get, it is called "info". You can use it the exact same way than the "search" command (this is the exact same code which is processing it).
The goal of this command is to provide more informations about a package. Here is an usage example :
$ ./slack-get info flightgear --media=slacky
Package: flightgear-1.0.0-i686-1as
Size (compressed): 3158 KB
Version: 1.0.0
Source: slacky
Description: The FlightGear flight simulator open-source project.The  goal  of  the  FlightGear project is to create a
sophisticated flight simulator framework for  use  in  research  or  academic environments,  for the development and pursuit
of other interesting flight simulation ideas, and as an end-user application
http://www.flightgear.org/ WWW.SLACKY.IT PackaGer Gohanz.


This little example, allow me to introduce the new command line option : --media. This one allow you to restrict the "search" or "info" commandes to the choosen media (in the previous example I wanted only results from the Slacky.it website).

Last about the slack-get cli client, I fixed lots of "non closing bugs". The non closing bugs are an annoying problem of slack-get cli client.
While the whole system became multitasks, it's becomming difficult to keep track of what the client asked by itself (particularly in a multi-administrators context), and after asking a sg_daemon to perform some tasks (and after the tasks are finished) the client does not end.
I corrected a lot of thoses problems.
A good example of this issue is with the "slack-get update" command. This one scheduled a tasks to upgrade all packages which have new ones in the patches/ subtree of the official-media (see config.xml). After the update, the client was not quitting. It is now corrected.
  • dynamic network backends negociation
Some of you may have noticed that sg_daemon should be able to dynamically negociate what network backends the client and it should use to understand each others. Until this morning it was not working, and it is now !
If sg_daemon supports XML and Base64 backends, and if the slack-get client supports XML and Gzip backends ; they will both agree on using the biggest common denominator (in this case they will use XML only).
I am very happy (and quite proud) of this mechanism. It allows tons of new development and many plugins to come !
  • lots of updates in the Slackware::Slackget Perl module
Last but not least I made tons of modifications in the Slackware::Slackget module. I added constants, generative methods to Slackware::Slackget::Media, add codes to Slackware::Slackget::GPG to support new import features, add method to Slackware::Slackget to check host's Slackware's version, and so on and so forth !

As a conclusion, I will just say that there is still some works to do but it's becomming to be a very usable tool. I'm using it every day now.
I hope all the work I made on slack-get will be of interets for you all !
As a bonus track I give you the new slack-get logo (that I made myself... so be kind ;-) )


Enjoy !

Arnaud Dupuis


Thursday 20 March 2008

Hardware failure and slack-get delay

Hi,
Like the title of this post can let you imagine, my main computer's hardware is all broken.
After a hard disk drive, replacement (87 EUR or 137 USD), a CPU replacement (190 EUR or 300 USD) I now need to replace my mainboard (225 EUR or 353 USD)...
All those thing leads to 2 things :
  1. I've no more money (so please enjoy a click on a google add ;-) )
  2. I spend a lot of time trying to go to the shop, and try to fix this damn computer.
The direct consequence is that the slack-get development diary is delayed until I fix my computer.
Why ? Just because there is an important pending SVN commit (waiting a data recovering) on one of my broken disk...

Sorry for the delay but hu...

By the way I strongly advice French preoples against the IT shops in Paris' "rue montgallet" unless they are willing to save 200 € on 1500 in order to cancel their hardware's garantuee.


Arnaud Dupuis

Monday 17 March 2008

New english data file for PKanaEditor

Hi,

I saw - thanks to users mails - that I only gave a french data file with PKanaEditor 0.2.
So I hereby correct this mistake by providing you (attach to this post) an english localized data file (PKanaEditor English localized data file).
I hope it will fit english speaker needs !

To use this file, you just have to download it, open PKanaEditor's settings, choose a "Custom..." data source and select the file you just download as the source.

In version 0.3 there will be an automatic OS language discovering. While I'm confessing about the next release I can also tell you that I'm rewritting the auto-completion engine. The current one is indeed... a bit buggy... It generally works not too bad but their is some important issues (for example when you hit the carriage return key, you have to also hit the space key or no completion is done...).
The new engine is way better because I put the code I wrote to the dustbin and I'm now using Qt's features... And wonder what ? It's A LOT better ;)

Oh and by the way the slack-get development diary will be back this week (probably on wednesday), because I have one or two little thing to tell you.

Enjoy!

Arnaud Dupuis.

Saturday 8 March 2008

PKanaEditor - The "P" Kana Editor v0.2 - windows binaries

Hi,
Since I'm currently working on a windows xp computer, I got the occasion to compile PKanaEditor on this platform.
So, attached to this post is the windows installer containing required Qt dll and PKanaEditor binary.

This version is provided for convenience without any guarantee it will work on your windows install ;-)

Enjoy !

Arnaud Dupuis

Monday 3 March 2008

PKanaEditor - The "P" Kana Editor v0.2 released

Hi,
After some weeks of kind of hard work, here is the 0.2 version of the "P" Kana Editor.
It's now fully rewrote in C++/Qt 4.x and that's one of the smallest changes I made !
I also add a configuration window and the editor now features an intuitive "kana" completion and an help system on completion's proposal !
Moreover PKanaEditor is now multiplateform and can be used on Linux based system but also on windows systems (only XP tested) and Mac OS X (hum... it should be...) and most of the UNIX based system (*BSD, etc.).
You can download the sources from Qt-apps.org or from here. The archive is also attached to this post.

The one thing I couldn't do for this release is to find a meaning to the "P" ;-)

I hope you will enjoy it !

Arnaud Dupuis

Tuesday 26 February 2008

Public test of the PKanaEditor main widgets (KanaEditor, KanaTextEdit and KanaListWidgetItem)

Hi,

I finished to implements almost all features I wanted for PKanaEditor 0.2... in the editor widget. Well that left some works to have a complete application working smooth and fine. But since the editor widget is almost finished, I would like to have some feedback.
So I hereby release the first alpha version of this editor. Please note that this is not the complete application, it do not allow you to save your work and do nothing else but to translate what you write from romanji to kana.

I still would like some feedback about the choice I made in the implementation.
I am particularly interested in your opinion about the following points :
  • the way the kana are automatically presented to user (the completion through the "helper" popup)
  • the contextual help system (when you let your mouse above a kana a tooltip with a big version of the kana and it's meaning (for kanjis) is drawn)
  • your global feeling about this editor.
Please keep in mind that this is only the editor part of the software !
There is still time before the release of the whole program. So if some brave souls could test this editor and give me interesting feedback, I could make it better.

In order to use this editor you have to compile it. This means you need Qt4 (at least 4.2.0 but 4.3.0 or newer is recommended), g++ and make.
To compile the code for your plateform you just have to do the followings :
qmake PKanaEditor.pro
make
./PKanaEditor


I tested it on GNU/Linux (Slackware+KDE) and Windows XP and it should compile and run on Mac OS X and most of the common Unice (*BSD, etc.).
Here is a screenshot of the windows xp version :


I hope you will like it !

don't forget: feel free to send me your feelings about this... Did I mention that I wanted feedback ?

Arnaud Dupuis

Monday 25 February 2008

PKanaEditor updates

Hi,
After some thoughs I choose to change the way the helper is shown in the KanaEditor.
The tab-based widget was not easy to use in real usage conditions.
So I changed the thing and made a new helper based on a single QListWidget.
Here is the new result on Linux/KDE :


And on windows XP :

I think the Japanese font installed on the windows I use are just crappy.
Else, I can't explain the difference in quality between the windows version and the Linux one.
Next time, I will try to compile it on apple's Mac OS X.

Last but not least, I made a Qt Designer plugin of this KanaEditor widget. And thanks to the guy of irc://irc.freenode.net#qt I fixed a damn semi-colon at the end of the class definition which was "preventing" my code to compile...

See you later.

Arnaud Dupuis

Wednesday 20 February 2008

PKanaEditor new version proof of concept

Hi,
I never talk about my private life (or very few), but this time it had an influence on my Open Source work !
So here is the information : I will be married by june !
And my futur wife and I decided to spend our honeymoon in Japan... So make the link by yourself between this journey and PKanaEditor ;-)

So I have begin to code a proof of concept in C++/Qt4 and with some surprise it works pretty good ! Have a look at this screenshots :


Moreover, my new mission force me to code under microsoft windows xp, so I tried to recompile this PoC under windows and it works too ! Have a look :


Dudes from Trolltech made some incredible works ! I know it works since years but I didn't put my hands on a windows computer  in more than 8 years, and at this time I wasn't programming at all... I was too young ;-).

I now lack the XML loading of the data file and this PoC will be a stable version :)

For those who are interested in Qt programming, I do the trick translating romanji to (hiraga|kataka)na|kanji by subclassing QListWidgetItem and adding a _romanji internal QString to this item. The actual displayed character is set as the item text. Pretty simple, like the major part of Qt programming !!

The only real problem is to find a new meaning to the "P" of PKanaEditor (because it originally means Perl Kana Editor)...

Arnaud Dupuis

Friday 15 February 2008

compatibility of the Slackware::Slackget Perl module version 0.15_99

Hi,
It looks like that the latest released version of the Slackware::Slackget Perl module is quite incompatible with the Solaris operating system.
I was expecting this kind of problem with this release because I added more tests to the test suite. And Slackware::Slackget, as its name said, is designed to run on Slackware GNU/Linux based distributions.
So before the 0.15 final release, in order to provide a very usefull test suite, I will add some more tests.
And unfortunately, I expect more issues... The more the test suite is accurate, the more it will point the problem with Slackware incompatible systems.

The problem with the Solaris systems is that the `file` command do not support the -b switch. I use the file command instead of a CPAN module to reduce the amount of dependencies of Slackware::Slackget but I will look at this and try to make the Slackware::Slackget::File class use a CPAN module if installed (like File::Type).

Arnaud Dupuis

Saturday 2 February 2008

Release: Slackware::Slackget v0.15_99 and SGNC documentation

Hi,

A new version of the Slackware::Slackget module was released few hours ago on CPAN.
This release features the followings changes :
    - modify Slackware::Slackget::File->filename() behavior to allow it to set the filename
    - fix is_heavy_word() method in Slackware::Slackget::Package, wich now return the correct result
    - update Slackware::Slackget::Date to make it fill the month-name from the month-number
    - update Slackware::Slackget::Date by overloading '<=>' and 'cmp'
    - changed all classes of the Slackware::Slackget module to be compliant with the slack-get naming convention (SGNCC : Slack-Get Naming Convention Compliant) (http://www.infinityperl.org/post/2008/01/30/slack-get-API-review)
    - add more tests to the test suite for the followings classes :
        * Slackware::Slackget::File (SGNCC & backward compatible)
        * Slackware::Slackget::Media (SGNCC & backward compatible)
        * Slackware::Slackget::Date (SGNCC& backward compatible)
        * Slackware::Slackget::Package (SGNCC & backward compatible)

It is tagged as a developers' release for the moment since all the test for all modified (SGNCC) modules, the documentation is not yet up-to-date considering all the changes made, and I still need some time to test if their is absolutely no side effects due to the changes I made in the API.

Arnaud Dupuis


SGNCC - Slack-Get Naming Convention Compliant : the new slack-get's naming convention document

Document purpose :

The purpose of this document is to "standardize" slack-get development by imposing a naming convention for both (but not only) : slack-get clients, sg_daemon, all Perl modules and the C++ library.
This include of course, all plug-in which can be released in the futur.

Vocabulary :

In the future, we will refers to the slack-get naming convention as :
SGNC: for Slack-Get Naming Convention.

Additionally, we will refers to SGNC compliant code as SGNCC (SGNC Compliant).

Scope of the SGNC :

All the code released under the "slack-get development team" label must be SGNC compliant (SGNCC).
More generally, all code released and packaged with slack-get must be (and will be) SGNCC.
The SGNC apply to all API visible method names. Every methods in a class or bundle must be SGNCC. By extension to this principle all methods in the sg_daemon, slack-get and the upcoming slack-get GUI have to be SGNCC.
All script released and packaged with slack-get should be SGNCC too. But in order to not slow down some developments it is acceptable to keep not SGNCC code in the branch/ SVN tree. If released with slack-get, this code will be optional at building and installation time. It will also be released in a different package.

Rules of SGNC :

We refer to functions and methods as the same generic term of "method".
The SGNC consist in the following 3 simple programing rules :
  1. a method name consist of lower case, English words where space are replaced with underscores ;
  2. if the method name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper  case.
  3. if a conflict was solved according to rule 2), and if the name conflicts with only one of the supported languages (Perl and C++), add a wrapper method around the renamed one, in order to comply with the rule 1).


The slack-get development team

Tuesday 1 January 2008

slack-get development diary #5

Hi !

First of everything : I wish you all an happy new year. May all your desires come to reality !

My own desire is to release a first version of the new slack-get daemon quickly as possible. I'm coding the real work for the upgrade and install actions (update, remove, search and the others are already working but the remove one was still not test on a real case).
Some things actually happened on slack-get development since the last diary.

Bugfixes

I fix a lots of (very old) bugs. For example, in the Slackware::Slackget::Base class (which is untouched since months), there was a bug and the FILELIST: tag from the packages text file was not removed correctly and was still present in the XML. This is now fixed.
I also improve a lot the way metadata are parsed by classes like Slackware::Slackget::Package by simplifying the parsing regular expressions.
Without turning this diary in a bugfixe list, I also modify some XML parsing behaviors in order to make the resulting data structure consistent over time. I modified the Slackware::Slackget::Package class quite a lot and it now parse itself the dependency fields in the packages metadata and translates them into XML. The impact of this is : a bigger XML file (packages.xml), and an increased loading time. But in the other end, all data are now completely parsed in the XML file and there is no extra work to do after parsing, and the dependency tracking is a lot easier (and actually quicker ^^).

Remaining bugs

There is still a bug in Slackware::Slackget::Network::Backend::Gzip. The backend which is in charge to compress and uncompress the network messages... Well it's not working at all, and worst i don't know why. But in the other hand, i have not tried a lot to fix this module. I focus on sg_daemon and slack-get for the moment (and the involved vital modules).
The Base64 and XML backends are still working fine.

Other stuff

You should also be aware that I'm trying to help as much as I can for the KDE 4.0 release, so until the 11th of January the slack-get's development will certainly be slowed down by my involvement in KDE 4.0 development.
And on the 11th of January i'm going to snowboarding in the Alps until the 20th of January ! So I will not be available at all during this time... Off course, because I'll be too busy trying to break some of my bones ;-)

Wednesday 19 December 2007

"slack-get update" command on the way !

Hi,
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :

That's all for today. See you later for the development diary.

Arnaud Dupuis.

Monday 10 December 2007

slack-get development diary #4

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.

Monday 3 December 2007

slack-get perl module change its name !

Hi,
Like I announced on the developers' mailing list, the slackget10 was about to die. It's now done. The PAUSE (Perl Authors Upload SErver) admins sent me an email confirming the creation of the Slackware::Slackget registered namespace on PAUSE/CPAN.
I will modify all the library to fit the new namespace and release the changes as soon as possible.
One more thing : I created a new branch on the SVN for the GUI tests ;-)

Cya,

Arnaud Dupuis

Tuesday 27 November 2007

New Network backend mechanism

Today I implemented the new slackget10::Network mechanism I wanted to. What is it you ask ?
Clearly something which will help everything to be super-easy to improve. As you may know (or not) the slackget10::Network Perl Module has been completely redesigned and will be largely recoded.
The changes are quite important and the API is completely new. It's now a front end module (like slackget10::Network::Connection is) and it aim at providing a unified interface for all kind of "protocol" implementation.
The idea is to answer the question : "what are you doing with an incoming network packet ?". The answer is simple : you decode it, you interpret it, you build the answer and you encode the answer before sending it.

Continue reading...

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

- page 1 of 2