Re: Cancellation architectural observations

> the rare cancellation case

abort is not a rare case, and an ignore that does not abort makes no sense
whatsoever.

If I am paying data and I've requested 10 tiles on a mobile maps based
sites and I search/go/locate somewhere else on the other edge on the world
it makes no sense to wait for the initial 10 tiles to downloads: either
because my cache won't hold them anyway due settings limitations or browser
behavior, or because I won't see the new location until new tiles requests
are queued behind old tiles.

We can drop downloads on XHR, there is a whatwg Fetch API proposal that is
based on network requests and AFAIK it does not provide a way to be
canceled (being Promise based)

A mechanism that tries to abort, instead of faking it, allows a faking
(read: ignore) logic to be implemented regardless, but not the other way
round.

Moreover, being sure about the end of the Network operation is a real-world
problem but not solvable here for the simple reason that my mobile network
could die anytime in the process, with or without ignored Promises.

So that maye my rejected error was triggered after the server already
updated ... how are we going to solve this anyway?

If the POST didn't explicitly complete, we could let the server know about
it with a lighter request, instead of keep sendong 25MB of image that you
realized is the wrong one ...
So, having real reactions on cancel/abort should be the only option, IMO,
so that we can solve explicit developers intent.

As summary: as a developer, I don't know yet which way is the best one, but
if there's a way to interrupt the execution, however it's going to be
called, I am expecting such explicit action to be done, and not to be
silently ignored, specially from the underlying logic ( network requests,
POST requests, download, preload, etc )

Please let's get this right, thank you.




On Mon, Mar 2, 2015 at 6:25 PM, Dean Tribble <tribble@e-dean.com> wrote:

> On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang <otakustay@icloud.com> wrote:
>
>> +1 to the ignore term, I’ve opened an issue about it in
>> https://github.com/promises-aplus/cancellation-spec/issues/14
>>
> I have little attachment to any term, but there's value in keeping
> terminology that has years of investment and use in other contexts. However
> "ignore" also has the wrong sense, because it implies that the computation
> completes anyway. That can be accomplished more easily by simply dropping
> the promise.
>
>> IMO the term cancel(or abort) and ignore are totally different things,
>> the former one means “do not continue, stop it right now” and the “stop”
>> state should be broadcast to everyone who is interested in the work, while
>> the latter means “I don’t care about the result anymore, just play it as
>> you like”, it means the async progress can be continued
>>
>  This goes back to some of the observations above: you cannot stop it
> "right now" because async notification is not synchronous; indeed the
> operation may already be complete before you stop it. Thus consumers of the
> result of a cancellable request need to be able to handle either successful
> completion or the cancelled state (which just looks like any other error
> that prevented completion).  Attempting broadcast to "everyone" adds
> complexity and resources that are needed only in the rare cancellation
> case. It's typically not only not worth the software complexity, but not a
> good idea. When you cancel a print job, the document editor should make
> best efforts in the background to stop requesting fonts, stop laying out
> print pages, stop spitting out pages on the printer, etc. but most
> importantly, it should start paying attention to my new edits and hang
> waiting for everything that might be involved in printing to wrap itself up.
>
>> In practice both scenario are commonly seen, we may abort a resource
>> fetch in order to save bandwidth and opened connections, or we may in other
>> side just ignore it since continue to complete the fetch can result in a
>> local cache, which speeds up our fetch next time
>>
> The resource point is important. That's the "don't care" scenario, not the
> "abort" scenario. It's the request processor that knows what cleanup is
> worth the effort. The initiator of the request only knows they don't care
> about the result anymore.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>