Download streams

[hmil]

Implementation of the long awaited download streams. Addresses half of #7 .
WIP status:

• working prototype
• tests
• validation
• readme

[hmil]

@sjrd Need your advice here. Monix needs an implicit Scheduler in order to use asFuture. The Scheduler is a subclass of ExecutionContext, which means that even though my interface allows the user to provide an ExecutionContext, I cannot use it because monix wants its own brand of ExecutionContext.

[sjrd]

Well, the enclosing apply method takes an Observable, so it depends on Monix anyway, right? In that case, I guess apply should require an implicit Scheduler rather than an ExecutionContext.

[hmil]

But what if the user uses his own ExecutionContext throughout the project and then imports RösHTTP. From our discussion in #34 , it seems that this is likely the case. In this situation the user is forced to use a Scheduler instead...

[sjrd]

Well, you can't have your cake and eat it too.

If you're basing yourself on top of Monix, you have to play by Monix' rules. If it wants an implicit Scheduler, then yes, you need to demand a Scheduler from your users. Unless you can internally synthesize a valid Scheduler from an ExecutionContext, but I doubt that (otherwise Monix would take ECs to begin with).

If you don't want to impose the Scheduler tax on your users (which, I agree, is desirable), then you cannot use parts of the Monix API that require Schedulers.

[sjrd]

Where's the definition of asFuture? Maybe it can be generalized upstream to work with a normal EC.

[hmil]

It seems that there is no way to avoid the Scheduler. Plus the user has to provide a Scheduler anyway if he wants to use the streaming interface.
I should then probably replace all ExecutionContext parameters with Scheduler instead to make the whole API more consistent.

[sjrd]

I should then probably replace all ExecutionContext parameters with Scheduler instead to make the whole API more consistent.

I don't think so. I think it's good to require as little as possible from your users. That way, say they're only using the batch APIs, they can use any EC they already have. If they're using the streaming API as well, they can have an implicit Scheduler, and it will also be valid for methods requiring an implicit EC because Scheduler <: EC.

[hmil]

The thing is that both the batch and streaming APIs are backed by the same stream-based backend call (which is what this piece of code is about). This avoids code duplication, reduces the risks of bugs and does probably have little effect on performance for basic usages. Therefore, a Scheduler is required even for the batch API.

[sjrd]

Ah, well ... I guess then it doesn't really matter all that much.

[hmil]

Response streams will emulate a streaming behavior in the browser because XHR does not allow true streaming. But there is hope! => #46

Chrome cannot timeout on the response body because it buffers the whole response before emitting any event (hopefully #45 should level things a bit).