Add blog for JS abort controller #1226
Conversation
Update the dec release table to point at the latest table and update the latest table versions with what has released. Add Dec to releases sidebar
* Updated the version number for storage
We fixed the packages that needed this hack/workaround so we can remove the workaround now.
* Update changeLog for Storage * Update 2019-12-java.md
* no runtime configuration for c. * add more wording on default options
* Clarified ServiceVersion Guidelines * review feedback
* Remove receive all bullet point. * Update versions. * Update notes.
* JS: Guidelines for tags to use * JS: Guidelines for tags to use * tags and hotfixes * Update text on preview packages Co-Authored-By: Jeff Fisher <xirzec@xirzec.com> * Update docs/policies/releases.md Co-Authored-By: Jeff Fisher <xirzec@xirzec.com> * hot fix -> hotfix Co-Authored-By: Jeff Fisher <xirzec@xirzec.com>
The focus of these changes is to add a line item for the Event Hubs package for the Event Processor client.
update java KV release notes
The focus of these chagnes is to tweak the service names used for the Event Hubs packages in order to make them more friendly.
* wording change in logging * adopt a bit from go * remove some redundent-outdated things. Add private constant. * fix include tag * heep->http
|
All feedback addressed, let me know if there are more suggestions! |
|
Was the second file "how q" added by accident? Might want to remove it from the PR. |
|
that extra file is very strange! I'll slice it out of the history. |
bterlson
requested review from
czubair,
johanste,
JonathanGiles,
KrzysztofCwalina,
kurtzeborn,
maggiepint,
mikeharder and
weshaggard
as code owners
|
Well clearly I messed up my filter-branch. |
|
Recreating PR. |
| repository: azure/azure-sdk | ||
| --- | ||
|
|
||
| Cancelling in-progress network operations is critical for many applications to maintain responsiveness and avoid waiting for pointless work to complete. For example, when downloading a large blob from Azure Storage, a user might want to cancel the download, and it would be nice if we could tell the Storage library that it doesn't need to download any more. Or, maybe your process got an interrupt signal because the node is no longer needed or needs to upgrade and you need to stop any in-progress operations and shut down as soon as possible. |
There was a problem hiding this comment.
Consider:
For example, here are some scenarios where you could utilize the request cancelling functionality that is built into the Azure SDK.
- User started to download a large file from Azure Storage, but cancelled the request.
- A process got an interrupt signal because the node is no longer needed or needs to be upgraded.
There was a problem hiding this comment.
If you feel strongly I can change it but I prefer what's there personally.
There was a problem hiding this comment.
If you like the paragraph form, consider rewording the last couple of sentences.
Here's an example:
Cancelling in-progress network operations is critical for many applications to maintain responsiveness and avoid waiting for pointless work to complete. For example, when downloading a large blob from Azure Storage, a user might want to cancel the download. It would be nice if the app could let the Storage library know that it can stop downloading it. Or, maybe your process got an interrupt signal because the node is no longer needed or needs to be upgraded. It would be nice if the app could stop any in-progress operations and shut down as soon as possible.
There was a problem hiding this comment.
Is your goal here to reduce sentence length/complexity? I will simplify. "it would be nice if" is a little wordy too, I'll try to get rid of it.
|
|
||
| ## AbortController & AbortSignal | ||
|
|
||
| `AbortController` and `AbortSignal` are [standard features in the browser](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) and are used with the [`fetch` API](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch) to abort in-progress network requests. The controller is responsible for triggering cancellation, and signals are responsible for notifying when cancellation is requested. This separation of concerns enables you to safely pass an abort signal without delegating the ability to cancel the signal as well. |
There was a problem hiding this comment.
It's unclear what you mean by delegating the ability to cancel the signal as well.
There was a problem hiding this comment.
Holding a signal doesn't allow you to cancel it, only holding the controller does. This separation of concerns means you can safely pass around a signal and still have confidence things won't cancel because a library you passed it in to is misbehaving, for example. Thoughts on how to clarify?
There was a problem hiding this comment.
Adding the text from your comment above would help.
There was a problem hiding this comment.
It's kind of a useless point I think. Objections to just deleting the last sentence "This separation of concerns enables you to safely pass an abort signal without delegating the ability to cancel the signal as well."?
Let me know any comments. Edits allowed from maintainers, so feel free to fix any minor issues you like 😀