Is the service trait pulling its weight?

[rklaehn]

I added the service trait as a scope for the additional data that you add to a request type.

The purpose of this is so you can use the same message in different services. See example below. GetRequest and PutRequest are used both for the user facing service and some internal service, and I could even define different response stream items or types for each message.

I originally thought that this might be useful, e.g. if your request types are from another crate, and you don't want to newtype them. But so far I have never actually done this.

WDYT @Frando ? Should we remove it and make things simpler, or are they worth it?

use external_crate::{GetRequest, PutRequest};

struct KvService;
impl Service for KvService;
#[rpc_requests(KvService, message = RequestWithChannels)]
#[derive(Serialize, Deserialize)]
enum Request {
  #[rpc(tx=oneshot::Sender<String>)]
  Get(GetRequest),
  #[rpc(tx=oneshot::Sender<()>)]
  Put(PutRequest),
}

struct InternalService;
impl Service for InternalService;
#[rpc_requests(InternalService, message = InternalRequestWithChannels)]
#[derive(Serialize, Deserialize)]
enum InternalRequest {
  #[rpc(tx=oneshot::Sender<String>)]
  Get(GetRequest),
  #[rpc(tx=oneshot::Sender<()>)]
  Put(PutRequest),
}

[matheus23]

After using irpc once (not much experience!) I'd say I didn't really make use of the Serivce abstraction, and I found the amount of different types one handles confusing. It's even hard to give them unique names!
KvService, KvRequest, KvRequestWithChannels or KvRequestMessage?

IMHO the fewer the better. Let's not optimize for the "power use" in this case, especially since it's still possible, it just needs another newtype in the power use case.