A few suggestions: CMake, C++, Python..
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.