When parsing binary protocols, we'v established an existing practice in Hydranode, using getVal<>/putVal<> methods in Utils namespace, and stringstreams, where the low-level IO methods take care of all the byte-swapping. This is used in eDonkey module, as well as for internal core things such as MetaData / PartData saving.

However, when parsing ascii data, normally one has to resort to either manual hacking using std::string-based tests, scanf() (*cough*), or Boost.Tokenizer. Neither of those are scalable enough for complex parsing. Thankfully, Boost has just the thing - Boost.Spirit library - Spirit is an object-oriented recursive-descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus-Normal Form (EBNF) completely in C++.

I'v used Spirit before in Hydranode, namely when parsing ipfilter files (mldonkey and emule formats), and the result was over 5 times faster than implementations using alternative parsing techniques, so speed isn't the issue. However, Spirit is rather complex framework, so learning it takes a while. The time will be well spent though, considering how much parsing we need to do in various Hydranode modules.

On the Core/GUI comm side, we know that UI programmers would prefer not to know anything about the underlying protocol - ideally, they'd simply interact with a well-defined API, which would hide the underlying implementation (in this case, TCP-based Core/GUI communication). As such, it is clear that a separate library must be created, called libhn_cgcomm, which would provide an API that User Interfaces can use to interact with the core. Behind the scenes, it shall communicate with the core libcgcomm module over CGComm Protocol. In the future, Java, Python etc bindings can be made of the library, allowing easy creation of User Interfaces in any programming language.

With that in mind, the first step for setting up proper Core/GUI communication is the design that library, since that is what the User Interface shall "see", and interact with.

Madcat, ZzZz