DUECA/DUSIME
DCO service functors

For creating generic interaction with channels, a functor mechanism is available.

This functor mechanism is used by the hdf5 logging, but can be used for other purposes as well.

The hdf5 logging capabilities for DUECA used a mechanism for directly processing data in the channel access code. Rather than "reading" data from a channel, for which client code needs to know, or investigate, the structure of the data, an operation can be directly requested from a dueca::ChannelReadToken . For the hdf5 logging, that operation is the writing of the DCO object data into a logging file.

After an initial implementation specific for hdf5 logging, which lived for a mere few days, I recognised the need for a generic mechanism, and created a set of functors that implement a specific type of service for a certain datatype. This page explains about the service functors.

Overview of functors

To clarify a bit, take the example of the HDF5 functors. The following set of classes is defined:

With the pair of functors, code that knows only about the service (through the functors' middle classes) can invoke this service for channel entries with DCO objects for which the service has been implemented.

The functor classes use inheritance to live in three different areas of code. The channel code knows the functor by the DCOFunctor and DCOMetaFunctor parents, that only allow

The client code knows the first child of this, which exposes the interfaces to the service. With this, the meta functor can be used to create a functor, and the functor data can be saved or viewed.

The DCO object code knows the most specific versions of functor and metafunctor objects, both specific for the DCO class and the service. The following figure gives an overview:

metafunctor.png
Functor and metafunctor classes

Code generation

To make functor generation for DCO objects accessible for developers, the code generator has been extended with a plugin mechanism. Plugins can be installed with the DUECA installation (generally /usr/share/dueca/DCOplugins ), the name of the plugin file (without the .py extension) defines the name of the service. The plugin files contain a single class definition, AddOn, which has a number of methods to print additional code for

Inspect the hdf5.py file to see how to create such an extension

What to do with this?

This has many possibilities for creating generic modules. What about serializing data to JSON or xml? Reading back and playing back data? Reading and assembling data in vectors for plotting on-line graphs?