Re: [fetch] Aborting a fetch (#27)

I believe it is much easier (and more desirable) to add a version of fetch that returns a Task than it is to change the definition of Promise. 

I'm afraid I've been unclear about what I mean when I say reference counting. What I really mean is subscription counting. Every task can keep a simple counter of the number of subscriptions that exist. This mechanism is totally outside of the garbage collector and implemented in plain old JavaScript. Because it is necessary for each consumer to explicitly unsubscribe, there is a clear opportunity to decrement the counter.

The Task I propose would have a "then" method which would have the same signature as a promise. However it would also be lazy and also have a get method which was used to actually retrieve the data. "Then" would not trigger the request, just create a new Task. The get method would be used to actually retrieve the data. You can see an example (minus the reference counting) here:

https://github.com/jhusain/compositional-functions/blob/master/README.md

Now subscription counting is simply a matter of counting the number of get calls in the system, not the number of references to the Task. This is how the Observables in Rx work, using flatMap for Compositon and forEach for consumption.



JH

> On Mar 30, 2015, at 5:45 PM, Andrea Giammarchi <notifications@github.com> wrote:
> 
> Agreed that ref count would be problematic for few reasons:
> 
> GC exposed and also unpredictable in its execution
> .then is a pattern that favorites chainability and for some reason people love chainability, meaning it's not so easy to count down to zero within a chain, there'll always be someone at the end, unreferenced, and already attached, am I right? So how the initial fetch is supposed to abort since everyone unable to stop it can detach itself? Is is about getting rid of the initially assigned fetch? And what if I am an asshole that keeps one of the chained thenable referenced? Is everyone else screwed?
> In any case, this perfectly summarizes my general disappointment with Fetch
> 
> Fetch is an excellent example of an API that should not use Promises, because it involves the use of a scarce resource (ie connections).
> 
> But since we are here ... I guess it's too late so let's try to be pragmatic and cover as many cases as possible, keeping in mind the initial ease goal that was fetch.
> 
> Shall we?
> 
> —
> Reply to this email directly or view it on GitHub.
> 


---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-87734127