Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Revision of the API based on Ralith's ideas. #9
I talked with @Ralith some more tonight and the idea he's been trying to explain finally clicked. The key that I wasn't getting before is that ruma-api would be used by both ruma-client-api and ruma/ruma-client. Using this approach, ruma-api is still agnostic to any particular HTTP library, but ruma-client-api can still have a general concept of the components of a request.
Instead of the dependency graph looking like this:
It would look like this:
ruma-api provides the
ruma and ruma-client simply bind ruma-client-api with iron and hyper, respectively, by providing another set of conversions between iron/hyper's request/response and ruma-api's abstract
I haven't finished spiking this out, as you can see from the TODO comments and failing build, but I wanted to share and get some feedback and perhaps some advice for the remaining implementation.
I'm also not sure what the associated
referenced this pull request
Jan 28, 2017
I think I understand this idea better now that I've looked at it again and thought about it. We would basically have the request and response types we were previously planning to add to ruma-client in ruma-client-api, right?
I'd love to see this compiling in any case, just so I could write an implementation for one endpoint in ruma-client-api + ruma-client with it and see how it works. I'll share my experience with the experiment with the previous API proposal soon too (remind me on matrix if I forget).
I finished implementing the example. Not as bad as I thought. I imagine we'll want to come up with a macro of some sort to reduce boilerplate, but maybe not.
Here's a direct link to viewing lib.rs so it's easy to read the code. I find it hard to see the new API clearly looking at a diff from master.