Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Move Opaques marshaling into Typelib #13

Open
jmachowinski opened this issue Aug 7, 2014 · 1 comment
Open

Proposal: Move Opaques marshaling into Typelib #13

jmachowinski opened this issue Aug 7, 2014 · 1 comment

Comments

@jmachowinski
Copy link
Member

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
Copy link
Contributor

doudou commented Aug 8, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants