Typekit round-up

Submitted by peter on Fri, 2010-10-22 10:20

RTT-dev

While the dust is still settling, I'd like to summarize where this whole
typekit discussion is going. First the observations:

* Both KUL and DFKI have reported not to be 'amused' with the boost serialize
-> xml format conversion. Arguments are: 1. not possible to have user
friendly XML (oxymoron), for example a string as an enum 2. Not possible to
differentiate xml representation (persistence) from scripting resprentation
(daily use). 3. Sometimes, it's impossible to write a serialize function, in
which case everything becomes very hard.

* The convertType() can be used to mimick the 1.x propertyDecomposition by
returnting a propertybag, but it won't work for nested/deep types (please
confirm).

* getMember() may return any data source, but in case it's a constant data
source, it can't be used by the XML marshallers

* When using the StructTypeInfo (which uses the boost serialize function), a
const of a type can't be decomposed. For example, try:

Deployer [S]> const ConnPolicy cp = ConnPolicy()
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
108.651 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
= {type = , init = , lock_policy = , pull = , size = , transport = ,
data_size = , name_id = }

Deployer [S]> cp.type
1422.591 [ ERROR ][Logger] Could not get reference to value of 'Struct' data
source of type ConnPolicy because it's not an AssignableDataSource.
Fatal Semantic error: ConnPolicy does not have member "type".

This is a limitation of how StructTypeInfo uses the boost::serialization
function. typegen uses this for example for the KDL::Vector type too and it
has the same problems

I don't have the complete picture yet, but I'd like to propose at least these
3 resolutions:

1. We will allow again to separately specify xml loading/unloading code, the
1.x way. It will basically come down to documenting convertType for it's
alternative use, and maybe renaming it to decomposeType() for clarity. The
signatures looks fine to me.

2. Fix the issues the (de)composeType functions still have, as we test the new
semantics.

3. Use getMember() for scripting, replacing the dotOperator() of 1.x. Only
fall back to getMember() for serialization if (de)composeType has not been
implemented.

Using these resolutions, users know now what to expect that should work and
can submit clear bug reports.

Left unresolved is the serialize function for types with not assignable
members, for example, that only return a const reference or a copy to data.
The workaround today is to not inherit from StructTypeInfo (which is the only
*type info* class using the boost::serialization code) until this is resolved,
and implement getMember() manually, and follow the 3 resolutions set out
above.

Also left unresolved is the use of your type for the mqueue transport, which
uses the boost::serialziation code to marshall your type to a buffer and back
to a struct. In case you couldn't use StructTypeInfo, you also can't use the
mqueue transport for your data type. There is now way around it, unless we
start extending the mqueue code severely, which is not a priority right now.

Despite all what has been said, if you don't provide generic access to the
internals of your types, we can't do seemless manipulation or marshalling. If
your type does not provide access to the boost::serialization function by
making all members public or making it a friend function, you will never get
full support for your type in Orocos. If you don't want public members, the
friend declaration is done by first declaring before your class:

namespace boost { namespace serialization {
    template<class Archive, class AType>
    void serialize(Archive& ar, AType& t, unsigned int version);
}}

The friend declaration in the class is :

   template<class Archive, class AType>
   friend void boost::serialization::serialize(Archive& ar, AType& t, unsigned 
int version);

Note that does not introduce any dependencies on boost or Orocos headers.

Peter

Typekit round-up

Submitted by peter on Fri, 2010-10-22 16:00.