Add z_bytes in the examples.

[evshary]

Now we use ZBytes to replace Value, and we should provide some examples for users to know how to do the transformation. Add z_bytes.rs in the example to help users know how it works. Waiting for https://github.com/eclipse-zenoh/zenoh/pull/1174 to be merged and need some update.

[JEnoch]

examples/README.md is describing each example. I think a description of z_bytes.rs purpose must be added here.

[JEnoch]

In the past we were often ask how to publish/subscribe with Protobuf encoding. Could be worth to add an example here, also to show any encoding is supported. @Mallets, your opinion ?

[wyfo]

We don't provide the way for user to create true custom encoding, the only thing they can do is to add a schema to zenoh/bytes, which impact performance. Encoding documentation talks about reserved ids, but user doesn't even have access to the id. Maybe it's time to add a public constructor for encoding, where user could use their own ids (checking that they don't use reserved ones).

[wyfo]

I would like to add a protobuf encoding directly to zenoh, because I imagine that's a fairly common used format, but there is no normalized content-type for it. See https://stackoverflow.com/questions/30505408/what-is-the-correct-protobuf-content-type. We can still use application/x-protobuf like Cloudflare does, as well as application/x-messagepack for example. The issue with encodings like protobuf or flatbuffer is that you need the associated schema, so users will have to add schema to their Encoding.

People also suggest to simply use application/octet-stream with the schema, like in https://stackoverflow.com/questions/55383771/mime-type-for-flatbuffers.

[JEnoch]

Sure, any encoding that is not self-descriptive requires the user to take care of the associates schema. Either making assumptions (my key expr a/b/c will always have MyType values), either passing the type name or full description as encoding suffix: application/x-protobuf;schema=MyType (but this increases metadata size).

But aside encoding name, my point was more on providing code examples on how to use for instance prost or serde-json with ZBytes.

[Mallets]

I would like to add a protobuf encoding directly to zenoh, because I imagine that's a fairly common used format, but there is no normalized content-type for it. See https://stackoverflow.com/questions/30505408/what-is-the-correct-protobuf-content-type. We can still use application/x-protobuf like Cloudflare does, as well as application/x-messagepack for example. The issue with encodings like protobuf or flatbuffer is that you need the associated schema, so users will have to add schema to their Encoding.

People also suggest to simply use application/octet-stream with the schema, like in https://stackoverflow.com/questions/55383771/mime-type-for-flatbuffers.

Protobuf is already present as part of the automatically optimized encodings: https://github.com/eclipse-zenoh/zenoh/blob/fc18f90310cd451a2f3d6e579dd9cfd9dba4bda6/zenoh/src/api/encoding.rs#L305

[wyfo]

How did I miss it... 🤦‍♂️

[wyfo]

application/protobuf doesn't exist in https://www.iana.org/assignments/media-types/media-types.xhtml. (but application/vnd.msgpack was added a few weeks ago) I'm not sure we should use unregistered media type...

[Mallets]

We can't support all types nor be limited to only registered types. Moreover, vendor media types are kind out-of-scope in the sense they could be whatever... application/protobuf was the proposal from IETF and I'd rather stick to that. In my opinion no changes are needed on that regards.

@evshary I agree we should add in the example how to serialize/deserialize complex formats like JSON, YAML and PROTOBUF.

[evshary]

@evshary I agree we should add in the example how to serialize/deserialize complex formats like JSON, YAML and PROTOBUF.

Sure. Working on it now.

[evshary]

@JEnoch @Mallets I think it's ready for another review now.