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

Sample accessors #822

Conversation

DenisBiryukov91
Copy link
Contributor

make Sample fields pub(crate),
provide accessors for external users,
mark existing sample-mutating methods as hidden and unstable.
Closes #817.

@eclipse-zenoh-bot
Copy link
Contributor

@DenisBiryukov91 If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

pub fn with_timestamp(mut self, timestamp: Timestamp) -> Self {
self.timestamp = Some(timestamp);
self
}

/// Gets the quality of service settings this Sample was sent with.
#[inline]
pub fn qos(&self) -> &QoS {
Copy link
Member

@Mallets Mallets Mar 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the put and delete builders we have explicit options to set the Priority and CongestionControl. I understand that this PR only addresses the accessor pattern and it does not modify the types exposed. I wonder if we should have priority() and congestion_control() instead of a generic qos()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends whether we want to provide an absolutely flat structure, or if we are ok, to group some related values under a dedicated accessor, to avoid polluting ide autocompletion list. We should also probably ask ourselves whether congestion control has something to do with the sample from design point of view ? It seems to me put(...).with_congestion_control(...) makes a bit more sense than sample.congestion_control().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it makes a bit more sense on the put(...) than on the sample? Given the sample contains all the information associated to the data + publication?

Copy link
Contributor Author

@DenisBiryukov91 DenisBiryukov91 Mar 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

put(ke, payload).with_priority(...).with_congestion_control(...) corresponds to the phrase : "publish this payload on this ke with specified priority and congestion control [values]".
sample.priority() - corresponds to the phrase: "[Give me] priority value this sample was published with. Compare this for example with sample.encoding() - which corresponds to "[Give me] encoding (or format) of this sample". As you can see in the latter case (and in case of put) we do not need to add any extra words (except prepositions/pronouns) beyond the ones present in the function call. This is different for sample.priority(). I believe as long as we need to add extra words to describe what a line of code does, we ought to add extra layers of indirection.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to quickly remark that the API and accessors should be the same on all bindings and languages, I wouldn't add a level of indirection in C for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we can have something like z_sample_qos_priority(sample) ?

@imstevenpmwork
Copy link
Contributor

@DenisBiryukov91 Can you link this to its relevant issue? If there's no yet, then you can create one using the release template if this is meant to be included in the next release. Make sure also to add the proper timelines

@milyin
Copy link
Contributor

milyin commented Mar 15, 2024

Integrating this. Further API changes, like flattening qos accessors, is easier to apply over this update

@milyin milyin merged commit 2e9db3f into eclipse-zenoh:protocol_changes Mar 15, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants