I'd love interfaces like the ones shown by
[requests](http://forum.nim-lang.org///docs.python-requests.org/en/master/) and
[unirest](http://forum.nim-lang.org///unirest.io)...
Yes, I think it should implement a generic stream. You can have more than just
async sockets, async files are a thing too and you can map the API of sockets
fairly well onto this generic streams API.
@_tulayang, I think that `asyncstreams` must implement generic streams, not
http. And API that you suggest can be implemented in asynchttpserver or another
http related module, but not in generic streams.
More opinions?
@vega
I think it is different between io of httpserver and stand stream. readChar
readData ... are not useful. I think we need apis like recvOnClientError
recvOnAChunk recvOn100Continue recvOnTimeout etc.
WIP is here:
[https://github.com/vegansk/asyncstreams](https://github.com/vegansk/asyncstreams)
> Thats why I want to write asyncstreams module for the standard library. What
> do you think about it?
Sounds like a good idea :)
I created the fork of asynchttpserver for the test:
[https://github.com/vegansk/asynchttpserver2](https://github.com/vegansk/asynchttpserver2)
where you can read entire body using `request.body.readAll`, get the length of
the request without reading it via `request.body.len`. And the main featur
Suggest to export the data received at each time, so that users can use this
api to customize how their datas are stored (copy to their buffer or disk
files).
Please create an issue for this.
Request body is readed in memory at once. So, we can't receive big `POST`
requests. Maybe we can introduce new type, `RequestBody`, that can be used to
get body as a string/file/stream/whatever, or maybe even handle
`application/x-www-form-urlencoded` or `multipart/form-data mime types`?
10 matches
Mail list logo
