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

Rkyv support? #437

Open
comath opened this issue Feb 23, 2024 · 0 comments
Open

Rkyv support? #437

comath opened this issue Feb 23, 2024 · 0 comments

Comments

@comath
Copy link

comath commented Feb 23, 2024

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:

#[tarpc::service]
trait Hello {
    async fn health(name: String) -> String;
}

This would derive a trait HelloRkyv which would be the zero-copy version of the serve trait for Hello. It would look something like this to implement

pub struct HelloEcho;
impl HelloRkyv for HelloEcho {
    async fn health(self, _: context::Context, name: &ArchivedString) -> String {
        format!("Hello, {name}")
    }
}

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>.

pub struct HelloRkyvClient {...};
impl HelloRkyvClient {
    async fn health(self, _: context::Context, name: String) -> RkyvBytes<String>  {
}

There's a bunch of details to work out.

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant