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

CDR De/Serialization #224

Open
sanderkukk opened this issue Nov 22, 2022 · 4 comments
Open

CDR De/Serialization #224

sanderkukk opened this issue Nov 22, 2022 · 4 comments

Comments

@sanderkukk
Copy link

Hello,

Is the current built in CDR using equivalent to openDDS XCDR1 or XCDR2 ?

@jhelovuo
Copy link
Owner

I do not know. The current built-in CDR serializer is according to Common Data Representation spec from OMG, in this document , Section 15.3. It may interoperate or may not.

So far, we have not implemented the XTypes specification.

Please do some experiments and tell us about your findings, so we know if we are missing something.

@willstott101
Copy link

AFAICT XCDR1/2 are defined in: https://www.omg.org/spec/DDS-XTypes and are extensions over CDR, however it looks like some of the extensions might be part of RTPS already - so you may already have some/most of it.

Would you be interested in separating out the serde lib in RustDDS to a standalone library? I have interest in trying to use it with CycloneDDS (where bindings are encouraged to encode messages themselves)

@jhelovuo
Copy link
Owner

If you mean the CDR serialization/deserialization parts, then yes, why not.

It is not in our current roadmap, and therefore not a priority item, but if you would like to do it, then please go ahead. Then you could use it independent of RustDDS if you like.

However, I would like to be the owner of that package/repo, as CDR serialization is an integral part of RustDDS.

@willstott101
Copy link

willstott101 commented Feb 14, 2023

Great, I don't have any particular roadmap for it either, but it's very useful to know that you would be fine with that happening. I wouldn't even mind it remaining in this repo as a second crate (using cargo workspace), but a second repo might make it easier to have more owners/contributors if that lib was used as a building block for other DDS-related crates.

If I explore this I'll make a new repo under my name and let you know, you can then feel free to push under your namespace, and I can retro-actively turn mine into a fork I suppose 👍

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

No branches or pull requests

3 participants