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
Just because I am lazy: will the changes that you are listing change the
current API ? Will the typekits generated by oroGen stay the same ?
Sylvain
Typekit round-up
On Tuesday 09 November 2010 16:48:29 Sylvain Joyeux wrote:
> Just because I am lazy: will the changes that you are listing change the
> current API ? Will the typekits generated by oroGen stay the same ?
Your 2.0/2.1 typekits should remain valid/working without modifications.
Peter
Typekit round-up
Hi Orocos-devs.
The online forum seems to be a bit buggy, so i try to reply to the Peter's original message "http://www.orocos.org/forum/rtt/rtt-dev/typekit-round?page=1" here.
I'am porting my apps from RTT 1 to RTT 2. Everything is ok, except for loading/storing properties to xml files.
As Peter says in its message :
"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. "
I agree with that. The 1.x interface was intuitive, and the compose/decompose implementation was clearly identified.
Now, i'am a bit confused for finding were i can tune the format of my type in xml.
My type is an array. I would like to store the name of the field as "[#]", instead of "Element#". Moreover, i think it should be the default to save the field with the same name we use in scripting for accesing it.
Thanks for your reading.
Paul.
Typekit round-up
On Tuesday 09 November 2010 10:45:17 paul [dot] chavent [..] ... wrote:
> Hi Orocos-devs.
>
> The online forum seems to be a bit buggy, so i try to reply to the Peter's
> original message
> "http://www.orocos.org/forum/rtt/rtt-dev/typekit-round?page=1" here.
>
> I'am porting my apps from RTT 1 to RTT 2. Everything is ok, except for
> loading/storing properties to xml files.
>
> As Peter says in its message :
>
> "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. "
>
> I agree with that. The 1.x interface was intuitive, and the
> compose/decompose implementation was clearly identified.
But redundant for most data types (structs). I will push a patch on master
that makes the current state of compose/decompose more explicit, and also
documents it. From there on, you should be able to continue. The trick is that
you may return the datasource of a Property<PropertyBag> in convertType()
which contains your decomposed code, and this will work.
>
> Now, i'am a bit confused for finding were i can tune the format of my type
> in xml.
>
> My type is an array. I would like to store the name of the field as "[#]",
> instead of "Element#". Moreover, i think it should be the default to save
> the field with the same name we use in scripting for accesing it.
It's not that simple. The '[]' brackets are not valid in identifier names and
might cause trouble down the road. Also a plain number (like '3') is not a
valid identifier name. That's why we chose 'Element#' in the XML format. The
XML format will accept any name, because nor the XML parser, nor the
properties interprete the name. But when interacting with scripting languages,
your format might break. Today, it probably won't because your type is
composed again before it is presented to the rest of the software.
Peter
Typekit round-up
Hi Peter
(...)
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.
(...)
I think it was a good interface to have a compose/decompose. Why haven't you kept the 1.X interface ?
I'm a bit confused with the 2.X interface because i haven't the control of my xml format.
For example, for my arrays, i would like to keep my old xml files. But now i don't understand where i can implement my old compose/decompose methods. I don't see where to tune the automatic serialization for controling the names of the fields.
Moreover, i see a function "serialize", but no un-serialize. The two ways encode/decode is less clear than before...
Paul.