As I have been working with the Xplico code for my work, I could not help but notice things that I would personally like to have incorporated into the project. Here are 4 particular changes/additions/modifications I would make..

CMake port. I notice that the project does not even use Autotools for its build system, and instead uses what appears to be raw, hand-written Makefiles. I don't really blame/(care about) this choice (Autotools is difficult - more difficult than just writing Makefiles) - it is just unexpected, because most projects I have encountered at least use autotools. I recommend an alternative to both Autotools and raw Makefiles - CMake. Ever since I first found CMake, I have used it for all of my C/C++ building needs. It is so easy to use in comparison to Autotools/makefiles that I now sometimes go out of my way to port projects to CMake. I highly recommend it for this project as well.

Object-oriented C++ port. I just don't like C anymore, and think everything should be object-oriented until there's a good reason to port it to C. I am probably biased (because I deal with more object-oriented projects/code, as opposed to C-style code), but I imagine that things would be better understood (both for newcomers and in the longrun) if things were organized in that way (maybe not). All of the PEI functions in xplico-src/dispatch/include/pei.h I can easily see becoming methods of a class (Pei, PeiComponent). Interfaces would be much clearer to see/understand at first glance - for example, it was weird for me to find that the interface that dispatchers need to implement was specified as some #define statements in dispatch/include/dispatch.h - it makes more sense to me to have those be methods of a IDispatcher() interface class. I hear more people know C though, and maybe the main Xplico devs are simply most familiar with C, and so started with that.

Update sqlite3_prepare() calls to sqlite3_prepare_v2() calls. This would be a small(er) change, but I don't know why the code uses sqlite3_prepare() as opposed to the newer (and officially suggested) sqlite3_prepare_v2() calls (see http://sqlite.org/c3ref/prepare.html). Maybe that is something that is planned, but just haven't gotten around to.

Python replacement of non-speed critical code (not all, but some). One example of where I would recommend Python to replace current C code would be with the command line user interface. I notice that the -h option says that command line arguments have to be in a certain order - I don't think that should be true; they should be in any order. Python's optparse module (and the newer argparse module) can handle all command line parsing easily - doing the same thing in C is just tedious and annoying to look at in comparison (I think). There are probably other places where Python could/should be used, but I would particularly recommend its use anywhere that is non-speed critical (Python is relatively slow). I just think that usability and productivity (programming in Python) beats operational speed (programming in C) most of the time, because you could just rewrite things in C/C++ later to make things faster (I know that sounds too idealistic, but it's true most of the time I think). I come from developing with a methodology like "prototype in Python; (production in)/(port to) C++ later, if and when needed".

---

I trust the core/main/experienced developers will reply with their thoughts/ideas with regards to these recommendations, possibly pointing out flaws in the suggestions - maybe there are good reasons not to take the recommendations stated above, and that it is also the case that I am unaware of them.

Another benefit of using CMake is that everything that gets built can be put in a separate build directory, as opposed to the way things currently are, where everything that gets built (and placed) in the source tree. After you type "make", all kinds of things clutter the source directory (the tmp and xdecode directories, *.o files, etc.). When working with Xplico, I (relatively) frequently have to do "make clean; make" to reset everything. Granted, things get cleaned relatively well when you do "make clean", it would be better if the trash weren't there to begin with, and instead be placed in another directory, which is what CMake can do. I think Makefiles are capable of this behavior though, but 1. I may be wrong, and 2. it may be possible, but might be a hack to do.

I just wanted to mention this because I just now experienced some trouble regarding this matter, and wished Xplico was using CMake so I would not have had to deal with it.

Hi kizzobot,
I do not know CMake, we wanted to use Autotools, but we never had the time to devote to it.

In the makefile there is a command to facilitate erasure of data only:

I agree with kizzobot's suggestion to use C++ and CMake. CMake is a cleaner way to creating portable makefiles. It has mechanisms to detect toolchains and libraries what makes the porting process more productive and is simple to learn.

Another suggestion I would like to add is to change the way dema looks for new files. Instead of searching sub-directories it would be better if it uses libinotify to receive new file events. Actually I'm trying to do that. I'm starting by creating a new dema.c with this implementation. Please correct me if I'm wrong but the entry-point to start decoding a file is SeDeStart right? Basically what I'll need to do is to receive events from inotify populate the needed structures and call SeDeStart to start decoding, am I right?

Thank you

Hi filipenf,
all you said is correct.
We are introducing libinotify for 1.0.3 version of Xplico. The next version 1.0.2 will use the actual version of DeMa.

Ciao.
Gianluca