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

payload API for zenoh-c #312

Closed
milyin opened this issue Apr 4, 2024 · 2 comments
Closed

payload API for zenoh-c #312

milyin opened this issue Apr 4, 2024 · 2 comments
Labels
api sync Synchronize API with other bindings release Part of the next release

Comments

@milyin
Copy link
Contributor

milyin commented Apr 4, 2024

After discussion which started with @kydos and continued with @Mallets, @DenisBiryukov91. @sashacmc , @milyin the following decisions were made about new payload API for zenoh-c

  • z_owned_payload_t is an opaque object which can be received as part of sample or reply (instead of pair (buffer,length) at this moment)
  • the access to data in the payload object is perfromed through reader interface, like in Rust. For c the interface is similar to file interface with read(), seek(), rewind(), etc. No direct access to memory is provided
  • the set of functions to decode payload into integer, string, double is provided. These functions corresponds to From<Payload> traits in rust
  • constructing new payload for sending was not discussed. It should be possible to construct playload from string, integer, double as in Into<Payload> traits in rust. The way to construct payload from arbirtary user data should be provided also. To be decided, how. Write interface for symmetry? Just construct from user-owned buffer? Allocate single zenoh-owned buffer? All these variants?
  • It's unclear how z_put() should accept payload object: by taking ownership or by loaning? Accepting it with taking ownership (with z_move) is more convenient, no need to additional drop. But in this case for sending same payload for multiple destinations the payload should support clone operation (rcinc). Should the payload support it?
@milyin milyin added the release Part of the next release label Apr 4, 2024
@milyin
Copy link
Contributor Author

milyin commented Apr 4, 2024

Additional point: encoder/decoders should be also applicable to values of the attachment. Though this is related to discussion about attachment interface and should be started from Rust. Issue to be created

@milyin milyin added the api sync Synchronize API with other bindings label May 29, 2024
@milyin
Copy link
Contributor Author

milyin commented May 29, 2024

@milyin milyin closed this as completed May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api sync Synchronize API with other bindings release Part of the next release
Projects
Status: Done
Development

No branches or pull requests

1 participant