Well, now Http is moving out of core. And it seems that abort is being considered as part of Http.Progress.
On Sunday, 2 October 2016 09:20:56 UTC-3, Matt Bray wrote: > > (Starting a new thread and moving to elm-discuss, as this seems out of > scope for the concrete task of moving Http to core.) > > On Sun, 2 Oct 2016, 10:33 Mark Hamburg, <[email protected] <javascript:>> > wrote: > >> From an API standpoint, it feels like the way to have requests that can >> be canceled is to make them subscriptions rather than commands. They get >> canceled when the subscription goes away. But this has its own set of >> oddities. For example, what one ends up with is essentially a subscription >> that delivers at most one value. What happens if it delivers that value, >> goes away, and then comes back — perhaps from the same Request descriptor? >> Does the reoccurrence receive a value as well? I can imagine an >> implementation — e.g., the corresponding effects manager would guarantee >> delivery of a value to any "open" subscriptions and would attempt to >> satisfy subscriptions with equivalent requests all at once — but I could >> also imagine this being rather sensitive to when the runtime calculated the >> desired subscriptions. In any event, however, if I were looking for a way >> to support cancelation — something that mostly seems sensible for GET >> operations — I would probably try to make it work using subscriptions >> rather than commands. >> >> Mark >> > > Have you read > http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Process#future-plans > ? This seems like the proper way to handle cancellation. > > However, as the planned API stands, I don't think it supports this use > case, because there is no "a" type variable in the return type of "spawn". > >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
