The data store module deals with on-disk storage. This includes Polykephal specific configuration (eg. IP/port to listen on), configuration stored using the icecap protocol config commands, networks/gateways/channels/presences setup and event / command storage and retrieval.

• Networks
• PK Configuration
• Icecap "config" options
• Gateways / Channels / MyPresences (these will be protocol specific and may have protocol specific parameters) - about the only thing that isn't either a flat text line or a key/value pair.
• Commands / Events (Both for logging and for icecap's event retrieval capabilities)

• QtSQL - supports many DB's, including MySQL, PostgreSQL, ODBC and Sqlite3.
• Flat file - particularly for basic configuration (PK Configuration), but could be used for other items such as "config" storage, Networks/Gateways/Channels/MyPresences and even event/commands.

Things to consider:

• Speed when dealing with large databases (particularly the events/commands storage and retrieval). One method I thought of to handle this was to log to plain text, and PK can simply check the first and last entries of all files in a directory to get the range stored in that file.

Flat file would be easy to handle for events / commands storage and retrieval. We could log the raw commands and events to plain text, with rotation based on date and perhaps filesize too (it might be a good idea to make this configurable, at least internally, so we can alter it with minimal changes if performance improvements are needed).

The range of id's stored in each file could then be stored in another file for fast lookups (otherwise we would have to generate this list on each run).

Files could be stored in a directory structure based on Network and Channel values (perhaps MyPresence as well, although this would be easy to filter internally anyway).

As well as serving as the command / event store, these files would double as log files that could be easily parsed by other software.

Flat files could be easily compressed with any popular compression algorithm (gzip, bzip2, lzma). Qt4 appears to have some built-in handling for zlib compression.

Relevent QT API:

• http://doc.trolltech.com/4.4/richtext.html
• http://doc.trolltech.com/4.4/text.html
• http://doc.trolltech.com/4.4/qbytearray.html#qCompress
• Look at code that handles .svgz (in the QtSvg module in 4.5 - src/svg/qsvgtinydocument.cpp:78 qt_inflateGZipDataFrom)
  • http://osdab.42cows.org/snippets/qtsvgzplugin.php?printable=yes&mode=advanced

Advantages: We want to do most of this for logging anyway, so implementation cost is low. If we find it too slow, we can implement a separate database instead relatively easily. If we can use this method, it will avoid unnecessary duplication of data.

I believe conversion or serialisation of objects should be handled within the data store itself. We should be able to create a generic method of conversion or serialisation that will work for any objects we are likely to use. Where we refer to other objects (ie. objects need to refer to a network), we can use a unique identifier (either an id field or, for example, the name field).

This would keep the serialisation / conversion coupled to the data store method, allowing it to be easily changed without affecting the objects themselves.