Comments (5)
Yes, it is more verbose and confusing than necessary. It should be improved, i.e. rewritten. I do not know of any technical reason to use the imperative style, but I am not the original author for this part. It seems to have been constructed by heavy use of copy, paste, and edit.
Rewriting could certainly improve this, but on the other hand:
- It takes some time and effort. Volunteers are welcome.
- Rewrite may introduce bugs. Now it seems somehow work. "If it is not broken, do not fix it."
Regarding "What is this object doing exactly?":
The purpose of BuiltinDataSerializer and the corresponding deserializer is to just (de)serialize some Discovery data types that the RTPS specification, Sections 8.5 and 9.6, mandates. I have been told that they are specified so that it not possible to use the usual CDR serializer/deserializer, but have not gone through the technical details myself.
This serialization is used to communicate with other DDS implementations, so it is important to follow the specification and check interoperability with others when doing any changes.
from rustdds.
@jhelovuo i hear you. not to be touched without some test coverage. #47 can help with that
from rustdds.
If my memory serves, the idea in BuiltinDataDeserializer
is that first it produces self by parse_data
method. The data on the wire is a tagged list of items, or a "parameter list" representation, and those are used to fill in the various Option
fields.
The self object can then be converted to various different types using generate_
-methods, depending on the context (or Topic, really).
The BuiltinDataSerializer
does basically the same, but in the other direction.
from rustdds.
I'm just starting to look at this in https://github.com/danieleades/rtps...
i'm forming the opinion that serde
is not the right solution (neither is speedy!).
- the specification does a good job of separating the platform independent spec from the UDP-specific elements. I think for maximum flexibility, the implementation should do the same. implementing serialisation within the platform independent modules breaks that encapsulation
- using a serde-based approach makes it difficult to add other modalities in future. For example you would bend over backwards to get the UDP serialization wire format correct by creating a very bespoke serializer, or by careful and bespoke implementation of
serde::{Serialize, Deserialize}
, or some combination of the two. This would then wreak havoc if you later wanted to create an independent platform-dependent implementation
I now the think the most appropriate serialization strategy is to create new traits (ToBytes
/FromBytes
, or ToCdr
/FromCdr
, something along those lines). These traits would handle conversion of the various types to and from the appropriate wire format. This also removes the coupling between the structure of the types in the crate and the structure defined in the specification. Additional platform specific constructors and other methods could also be implemented separately, in a platform-dependent module.
pub trait Cdr {
type DecodeErr: std::error::Error
fn as_bytes(&self) -> Vec<u8>;
fn from_bytes(bytes: impl AsRef<&[u8]>) -> Result<Self, Self::DecodeErr>;
}
that doesn't mean to say that types couldn't selectively make use of speedy or serde as helpers for implementing the Cdr
trait, if that's useful.
Adding a new platform-dependent modality would involve creating new traits, and would be entirely decoupled from the UDP implementation.
from rustdds.
This is a duplicate of issue #32 .
from rustdds.
Related Issues (20)
- Malformed locator triggers panic while the port field is being unwrapped HOT 2
- Malformed `readerSNState` in ACKNACK submessage triggers panic (add overflow) HOT 2
- Remotely reachable `todo!()`s HOT 2
- panic due to a malformed INFO_REPLY submessage HOT 2
- busy looping on DataReader.take() HOT 6
- Bug in the example code shape_demo_mio_08? HOT 1
- Durable writer only keeps/sends samples written after some time HOT 3
- How to tell if a discovered topic is for a reader or writer HOT 3
- Derive serde::{Deserialize, Serialize} for QosPolicies HOT 1
- Access SampleInfo from async reader interface HOT 1
- Sample source timestamp not preserved for separate domain participants HOT 2
- Reliable reader delayed reception of FastDDS shapes HOT 4
- Why does my subscriber miss the first 2 published samples? HOT 5
- Reception lag of 2 samples with some QoS settings HOT 3
- Interoperability problem with OpenDDS Shapes demo HOT 4
- On mac air with m1 chip , find cannot bind the request address HOT 1
- High latency for large messages HOT 1
- DDS Generator HOT 4
- Identified multiple memory leaks in listeners HOT 3
- Received unknown submessage kind HEARTBEAT_FRAG HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rustdds.