Server/Client-as-a-Function

[benjchristensen]

To achieve aspects of the use cases (#14) @NiteshKant and I propose that we treat servers and clients as functions that can be composed. For the rest of this I'll talk about servers, but it applies to clients as well.

It effectively behaves like "mapping" a server to a new server. This is somewhat monadic, except we don't think there is ever a time a Server<Server<I, O>> makes sense, so it won't have flatMap/bind so isn't actually a monad. It works quite similarly though so one should be able to define a server:

Server<I, O> s = ...

and then transform it into a new server definition with additional behavior such as logging:

// pseudo-code
Server<II, OO> s2 = s.intercept(server -> {
 // do logging here
 return server; // pass thru as we are just side-effecting with logging
});

and then transform data:

// pseudo-code
Server<II, OO> s3 = s2.intercept(server -> {
 return Server.create((ii, oo) -> {
    i.subscribe(input -> {
       // manipulate data, enrich it, etc
       return output; // handwaving here
    });
});
});

In a few days @NiteshKant and I will submit a PR proposing this approach to making RIPC loosely-coupled yet capable of achieving the many use cases #14 via layering and composition.

[benjchristensen]

Here is a paper by Marius at Twitter (who created Finagle) that should influence our design: http://monkey.org/~marius/funsrv.pdf

[benjchristensen]

Here is another example from Retrofit: http://square.github.io/retrofit/javadoc/retrofit/RequestInterceptor.html