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

[junglie85]

Problem description
Writing events requires a Vec<u8>.

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

[vangork]

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]

How does that differ from the byte api which does take a slice?

pravega-client-rust/src/byte/writer.rs

Line 158 in 8ea1ecb

pub async fn write(&mut self, buf: &[u8]) -> Result<usize, Error> {

[vangork]

the slice would acutually be cloned into vec right away.

pravega-client-rust/src/byte/writer.rs

Lines 159 to 160 in 8ea1ecb

	let bytes_to_write = std::cmp::min(buf.len(), EventWriter::MAX_EVENT_SIZE);
	let payload = buf[0..bytes_to_write].to_vec();

[junglie85]

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?