Sha256: 7d763601ce6f917b275c73a0ac6ba3fa4e94e58fec424e8f696ee7898f0ca64b
Contents?: true
Size: 1.55 KB
Versions: 5
Compression:
Stored size: 1.55 KB
Contents
# HTTP Client Agent The concurrency model and the fact that we want to serve the response object on receiving headers and let the user lazily read the response body, means we'll need to change the API to accept a block: ```ruby # current API resp = Agent.get('http://acme.org') puts resp.body # proposed API Agent.get('http://acme.org') do |resp| puts resp.body end ``` While the block is running, the connection adapter is acquired. Once the block is done running, the request (and response) can be discarded. The problem with that if we spin up a coprocess from that block we risk all kinds of race conditions and weird behaviours. A compromise might be to allow the two: doing a `get` without providing a block will return a response object that already has the body (i.e. the entire response has already been received). Doing a `get` with a block will invoke the block once headers are received, letting the user's code stream the body: ```ruby def request(ctx, &block) ... connection_manager.acquire do |adapter| response = adapter.request(ctx) if block block.(response) else # wait for body response.body end response end end ``` # Roadmap: ## 0.25 Full Rack adapter implementation - Work better mechanism supervising multiple coprocesses (`when_done` feels a bit hacky) - Add supervisor test - Homogenize HTTP 1 and HTTP 2 headers - upcase ? downcase ? - find some demo Rack apps and test with Polyphony ## 0.26 Working Sinatra application - app with database access (postgresql) - benchmarks! ## 0.27 Testing & docs
Version data entries
5 entries across 5 versions & 1 rubygems
Version | Path |
---|---|
polyphony-http-0.28 | TODO.md |
polyphony-http-0.27 | TODO.md |
polyphony-http-0.26 | TODO.md |
polyphony-http-0.25 | TODO.md |
polyphony-http-0.24 | TODO.md |