#[norpc::service]
trait Pub {
  fn message_stream(st: Stream<Elem>) -> Stream<Elem>;
// or
  #[stream]
  fn message_stream() -> Elem; // output only?
}

yields fn message_stream(self) -> Pin<Box<dyn futures::stream::Stream<Item = Elem>;?

I don't know. Need some experiments.

Discussed in https://github.com/akiradeveloper/norpc/discussions/35

v0.6.0

The both should be accepted but failed to compilation due to "unexpected token".

diff --git a/example/kvstore/tests/kvstore.rs b/example/kvstore/tests/kvstore.rs
index 13c0abf..787cf6b 100644
--- a/example/kvstore/tests/kvstore.rs
+++ b/example/kvstore/tests/kvstore.rs
@@ -9,7 +9,7 @@ trait KVStore {
     fn write(id: u64, s: String) -> ();
     fn write_many(kv: HashSet<(u64, String)>);
     // We can return a result from app to the client.
-    fn noop() -> Result<bool, ()>;
+    fn noop() -> std::result::Result<bool, ()>;
     // If app function fails error is propagated to the client.
     fn panic();
 }

diff --git a/example/kvstore/tests/kvstore.rs b/example/kvstore/tests/kvstore.rs
index 13c0abf..cc05bc6 100644
--- a/example/kvstore/tests/kvstore.rs
+++ b/example/kvstore/tests/kvstore.rs
@@ -7,7 +7,7 @@ use tokio::sync::RwLock;
 trait KVStore {
     fn read(id: u64) -> Option<String>;
     fn write(id: u64, s: String) -> ();
-    fn write_many(kv: HashSet<(u64, String)>);
+    fn write_many(kv: std::collections::HashSet<(u64, String)>);
     // We can return a result from app to the client.
     fn noop() -> Result<bool, ()>;
     // If app function fails error is propagated to the client.

Changing

#[norpc::service]
trait KVStore {
    fn read(id: u64) -> Option<String>;
    fn write(id: u64, s: String);

to

fn write(...) -> ()

makes it uncompilable.

I am thinking of generating functions that returns anyhow::Result<T> for definition that returns T.

Reason one is, while implementing two applications with library I found that calling unwrap in async function is sometimes problematic. async function that panic can not be used with parallel execution tools like BoundedUnordered because failing one future in a row results in failing the entire execution. To work around I need to write this function to return Result. This is very weird.

pub fn into_safe_future<T: Send + 'static>(
    fut: impl Future<Output = T> + Send + 'static,
) -> impl Future<Output = Result<T, JoinError>> {
    async move { tokio::spawn(fut).await }
}

Reason two is analogy to Tonic. Tonic generates a function that returns Result<T, tonic::Status> for a definition that returns T. And tonic::Status is just like (HttpCode, String). norpc is a library to define a in-process service and this is kind of in-process version of Tonic so it is not unnatural to norpc also generates a function that returns Result<T> as well.

So the question what should be the Error type? I think Result<T, String> will suffice but anyhow::Result will be more convenient.

As of Rust 1.57 we can't define a struct field as like this

struct T {
  svc: impl Service
}

The resulting concrete Service type from a ServiceBuilder may be very complex that's practically impossible to hold an ownership to the client that holds the Service.

To workaround this, BoxService or BoxCloneService can be used as indirection layer.

This should work but it doesn't.

    let mut cli = RateLimitClient::new(chan);
    let mut cli = cli.clone();

error[E0599]: the method `clone` exists for struct `RateLimitClient<tower::limit::RateLimit<ClientChannel<RateLimitRequest, RateLimitResponse>>>`, but its trait bounds were not satisfied
  --> example/rate-limit/tests/rate_limit.rs:35:23
   |
7  | #[norpc::service]
   | -----------------
   | |
   | method `clone` not found for this
   | doesn't satisfy `_: Clone`
...
35 |     let mut cli = cli.clone();
   |                       ^^^^^ method cannot be called on `RateLimitClient<tower::limit::RateLimit<ClientChannel<RateLimitRequest, RateLimitResponse>>>` due to unsatisfied trait bounds
   |
  ::: /home/akira.hayakawa/.cargo/registry/src/github.com-1ecc6299db9ec823/tower-0.4.11/src/limit/rate/service.rs:14:1
   |
14 | pub struct RateLimit<T> {
   | ----------------------- doesn't satisfy `_: Clone`
   |
   = note: the following trait bounds were not satisfied:
           `tower::limit::RateLimit<ClientChannel<RateLimitRequest, RateLimitResponse>>: Clone`
           which is required by `RateLimitClient<tower::limit::RateLimit<ClientChannel<RateLimitRequest, RateLimitResponse>>>: Clone`
   = help: items from traits can only be used if the trait is implemented and in scope
   = note: the following trait defines an item `clone`, perhaps you need to implement it:
           candidate #1: `Clone`

The reason seems the tower::limit::RateLimit doesn't impl Clone. Without the line, it compiles.

    // let chan = ServiceBuilder::new()
    //     .rate_limit(1000, std::time::Duration::from_secs(1))
    //     .service(chan);

Cloning decorated channel doesn't mean anything so this is ok but this is a bit convenient.

If the code-generator generates Result<T> in the trait as Result<T> = Result<T, Self::Error> it will be very convenient but the feature (generic associated type) isn't supported by the compiler at the moment.

#[norpc::async_trait]
impl HelloWorld for HelloWorldApp {
    type Error = ();
    type Result<T> = Result<T, ()>;

To have a client in a struct field we need a complicated type like this.

IdStoreClient<ClientChannel<IdStoreRequest, IdStoreResponse>>

How about generate type alias like IdStoreClientT for convenience?

If service has only one method, the unreachable!() arm will be warned by the compiler. Let's suppress this.

warning: unreachable pattern
--> /home/runner/work/norpc/norpc/target/debug/build/concurrent-message-05ff294aa07abe07/out/concurrent_message.rs:30:5
|
30 | _ => unreachable!(),
| ^
|
= note: `#[warn(unreachable_patterns)]` on by default

Currently, norpc only supports mpsc channel but in some case broadcasting is a good fit.

https://docs.rs/tokio/1.16.1/tokio/sync/broadcast/index.html

Typical use case is that a micro service receives a message from outside the process (by gRPC for example) and broadcast the message to N subscribers.

I think this code is not correct. ClientService should poll the channel before calling call.

impl<X: 'static + Send, Y: 'static + Send> crate::Service<X> for ClientService<X, Y> {
    type Response = Y;
    type Error = Error;
    type Future =
        std::pin::Pin<Box<dyn std::future::Future<Output = Result<Y, Self::Error>> + Send>>;

    fn poll_ready(
        &mut self,
        _: &mut std::task::Context<'_>,
    ) -> std::task::Poll<Result<(), Self::Error>> {
        Ok(()).into()
    }

We could possibly use PollSender in tokio-util to make Sender pollable.