(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]> 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.
