Clarify the goals of the project

[greglaun]

I've been checking in on this project for a little over a year, and I'm still unclear on what its ultimate goals are. Would you mind adding a few sentences to the README that indicate what role you want this library to play?

For example, it seems like it could be doing two different things at this point:
(1) An implementation of a subset of gRPC using concepts familiar to the Haskell community, but unfamiliar to the gRPC community, or
(2) An implementation of gRPC using Haskell libraries only (e.g. not wrapping the C implementation, the way Awake Security is doing).

(Or maybe it's something else, like just the library that serializes proto messages over HTTP2.)

In my opinion, clarifying this would make it easier for other developers to help you achieve your goals. As it stands, it's a bit unclear what sorts of bug or code contributions would be most helpful.

Based on the examples I've seen using this library, it looks like the current state is closer to (1). For example, PR #35 has the client directly import newHttp2FrameConnection. Also, in GitHub search I see no code for many of the important high level gRPC concepts, like "channel", "stub", "context", etc. Since HTTP2 is really an implementation detail of gRPC, it seems like this library is a little lower in the stack than other gRPC libraries.

Or, put another way, it seems like the examples mix too many layers of abstraction in the same file (e.g. handlers and HTTP2) which would ordinarily be separated by abstraction. Generally in gRPC I can express the entire server and client without thinking about lower-level concepts like HTTP2 or TCP connections. For example, if you look at the gRPC examples for other languages, you'll typically find that they depend only on gRPC and a few other common libraries.

Hence my question at beginning. Is the goal to do a re-imagining of gRPC in a more Haskell-y way, possibly with the side effect of never achieving full compatibility with the rest of the gRPC ecosystem? Or is it to implement stock gRPC using idiomatic Haskell?

In the first case, (in my opinion) the road is going to be very hard. You'll have to essentially re-design gRPC from scratch, since you'll be running into and solving problems that the existing gRPC spec already has solutions to. In the second case, the road will be moderately hard because the existing solutions were developed in the land of OOP, but arguably easier to parallelize since it will largely be a matter of porting existing concepts to Haskell.

Either way, I think it's a cool project. Thanks!