Proposal: Move Opaques marshaling into Typelib

[jmachowinski]

Hi,
at the moment we can not build standalone tools, that handle
any typelib types which contain opaques. The reason for this is
that the opaque demashaling is in the orocos code base.

Therefor I would like to make the proposal, to move the marshaling
code into typelib itself. What I mean by this is, to add some type
of plugin system for opaque marshalers, and a system, to load
an opaque plugin for a given opaque type name.
Greetings
Janosch

[doudou]

I am 100% for separating the opaque marshallers from RTT but 100% against
moving them into typelib.

The core feature of typelib-based tools is that they are self contained,
i.e. one does not need binary code to read the data. This is what makes
pocolog files readable years after the types changed, or allow to "upgrade"
pocolog files to the newer types. I want to keep typelib 100% free of
anything that breaks this property.

Now, I think it would be an awesome idea to totally support creating a
separate tiny library for Rock that would handle the opaque marshalling,
thus removing the need for RTT when we want to call Qt methods (which, I
believe, is currently the main use-case). We however get back to finally
choosing a proper plugin system for Rock...

On Thu, Aug 7, 2014 at 5:30 AM, jmachowinski [email protected]
wrote:

Hi,
at the moment we can not build standalone tools, that handle
any typelib types which contain opaques. The reason for this is
that the opaque demashaling is in the orocos code base.

Therefor I would like to make the proposal, to move the marshaling
code into typelib itself. What I mean by this is, to add some type
of plugin system for opaque marshalers, and a system, to load
an opaque plugin for a given opaque type name.
Greetings
Janosch

—
Reply to this email directly or view it on GitHub
#13.