<@UBV8BCQPJ>: i had seen `chttp`
# development
w
@red-balloon-89377: i had seen
chttp
r
Thanks! That looks great, except it has no option for async requests that I can see. The actual reading and storing of the file can be async, because it returns a stream, but nobody can save us from the network latency. That said, even if we were to make the request async, we do wait for it to complete before returning from the node execution, so we’d probably not be gaining much?
w
Yea, I think the API in the ticket was currently blocking anyway. This would be a stopgap
@red-balloon-89377: There is a CpuPool that we can/should run this kind of work on to avoid blocking the tokio threads... I forgot to mention that in the review.
Will comment
r
Okay, cool 🙂 thanks.
@witty-crayon-22786 You might want to check out the comment I just left regarding the travis failures
w
yea, saw that. thanks
r
Would you like me to keep trying to figure out the SSL error with
reqwest
? If we eventually need to switch it would be useful, but I don’t have a good intuition of how much of a stopgap
chttp
is.
w
i'm going to look into the segfault i think.
@red-balloon-89377: are there any other issues that look interesting for you?
the "improve engine UI" one is relatively small, without dependencies
r
Sounds good 🙂
w
the "Consume logger/console" one would interact fairly heavily with python code, but is otherwise fairly small
r
I thought that was going to be a bigger one
w
yea, it would be. i take that back. "medium to large"
r
Assuming I will be ooo for most of next week, I think the improve engine UI is better
w
ok, yes please!