search

pravega / pravega-client-rust

Rust based Pravega client.
Apache License 2.0
31 stars 25 forks source link

Can write_event take a `&[u8]` instead of a `Vec<u8>`? #412

Open junglie85 opened 1 year ago

junglie85 commented 1 year ago

Problem description Writing events requires a Vec<u8>.

Suggestions for an improvement Make writing events requires &[u8] like the byte API.

vangork commented 1 year ago

The writer event call would send the event in a backend tokio task asynchronously other than from the main task. &[u8] can't guarantee the event won't be changed in the main task.

junglie85 commented 1 year ago

How does that differ from the byte api which does take a slice? https://github.com/pravega/pravega-client-rust/blob/8ea1ecb594e60a79aff52edfabb41c1ea5aa51cb/src/byte/writer.rs#L158

vangork commented 1 year ago

the slice would acutually be cloned into vec right away.

https://github.com/pravega/pravega-client-rust/blob/8ea1ecb594e60a79aff52edfabb41c1ea5aa51cb/src/byte/writer.rs#L159-L160

junglie85 commented 1 year ago

It'd be helpful (cognitively) for the interfaces to be the same. I don't mind whether it's a slice or a vec that is passed in, but I think consistency is good.

I'd normally try to pass a slice because it's more flexible. However, where low latency is key, I can also envisage scenarios where a custom allocator might be preferred instead of the global allocator in the owning vec (when the allocator API is stable). In the latter case, passing in a vec might be more expressive of the ownership situation.

Could the API be re-written to support both options to give greatest flexibility?