You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be awesome if this supported zero-copy rkyv in addition to serde. It's a bit more complicated as the types the client and server operate on are different to the types in the trait definition. I'm moving types with large vectors and buffers around in my distributed application and rkyv saves a lot of time over bincode.
We can have a transport that deserializes the rkyv bytes so we can re-use the regular HelloClient. A zero-copy client would be different as it should also return archived values. These are borrowed from a buffer, so the buffer needs to also be returned. We'd need a RkyvBytes<T> { ... } struct that has a function that returns the archived value &Archived<T>.
How does the rkyv server trait interact with the normal server trait?
Should the return type of the server be the RkyvBytes<T> struct? This would put the impetus on the author to archive which most won't need, but some might like.
How would the transport trait/objects interact with this? I think it'll need a new separate transport type as this is quite different.
I'd like it to work out that if you have a server object like HelloEcho that implements both the normal server trait and the rkyv one that you can set up normal clients locally that don't need serialization, and rkyv clients remotely for things that do.
This might be something to fork from this, but it might done within this crate.
The text was updated successfully, but these errors were encountered:
I think it would be awesome if this supported zero-copy rkyv in addition to serde. It's a bit more complicated as the types the client and server operate on are different to the types in the trait definition. I'm moving types with large vectors and buffers around in my distributed application and rkyv saves a lot of time over bincode.
Here's a mockup:
This would derive a trait
HelloRkyv
which would be the zero-copy version of the serve trait forHello
. It would look something like this to implementWe can have a transport that deserializes the rkyv bytes so we can re-use the regular HelloClient. A zero-copy client would be different as it should also return archived values. These are borrowed from a buffer, so the buffer needs to also be returned. We'd need a
RkyvBytes<T> { ... }
struct that has a function that returns the archived value&Archived<T>
.There's a bunch of details to work out.
RkyvBytes<T>
struct? This would put the impetus on the author to archive which most won't need, but some might like.I'd like it to work out that if you have a server object like
HelloEcho
that implements both the normal server trait and the rkyv one that you can set up normal clients locally that don't need serialization, and rkyv clients remotely for things that do.This might be something to fork from this, but it might done within this crate.
The text was updated successfully, but these errors were encountered: