Stuck on an issue?

Hello,

This library looks wonderful. One thing that makes it a bit hard for us & probably other folks to adopt & use is that it escew’s the web (and increasingly the rest of js too) standard AbortSignal cancellation protocols.

There are some various api differences between the standard JS abort protocols & the CancellationToken presently in use in cockatiel. The main difference is that CancellationToken is both the means to observe change, and the system for doing the change. This is reminisce of the old jQuery Deferrable, which was a precursor to promises, where the Deferrable was both the promise & the resolver. In JS today, usually the thing that does the actuating/changing is separate from the system for observing. That is reflected in AbortSignal and it’s pair AbortController, where AbortSignal is the output (somewhat alike a sychronously readable Promise), and AbortController can be used to actuate the signal (quite strongly resembling the obsolete JS Deferred, which contrary to jquery, divided the promise & the resolver ala AbortSignal/AbortController). First used in Fetch, today, AbortSignal is being widely integrated into the JS ecosystem.

Please pardon my long-windedness above. I find it interesting to provide some historical roots for the topic, as they show how things have moved over time, but I am mainly writing this ticket to talk about today & the future & how cockatiel can be the best JS citizen it can be. CancellationToken has a pretty nice, convenient, & very powerful set of APIs atop it, and I generally commend the Microsoft teams that have shaped it over the years. However, I feel like it’s in cockatiel’s best interest prefer to integrate with the JS language ecosystem, if possible, and feel like we should try to switch to AbortSignal/AbortController as the primary means to handle/deal-with cancellation concerns.