From c4e21c2842c64d100a90dc5b4cfd24692d5454ab Mon Sep 17 00:00:00 2001 From: Tyler Butler Date: Mon, 2 Dec 2024 10:24:10 -0800 Subject: [PATCH] Update changesets/readme --- .changeset/new-hats-learn.md | 9 +++++-- .changeset/shy-files-jam.md | 28 +++++++++++++------- RELEASE_NOTES/2.11.0.md | 38 ++++++++------------------- packages/framework/presence/README.md | 10 +++---- 4 files changed, 41 insertions(+), 44 deletions(-) diff --git a/.changeset/new-hats-learn.md b/.changeset/new-hats-learn.md index 593e00cd806b..6f2a76b20aae 100644 --- a/.changeset/new-hats-learn.md +++ b/.changeset/new-hats-learn.md @@ -1,14 +1,19 @@ --- "@fluidframework/core-interfaces": minor "@fluidframework/tree": minor +"@fluid-internal/client-utils": minor --- --- "section": other + +# Since this doesn't affect external users of the framework, exclude from the release notes but +# include in the per-package changelogs. +"includeInReleaseNotes": false --- The events library has been moved from the tree package -The tree package contains an events library. The events library's types and interfaces have been moved to -`@fluidframework/core-interfaces`, while its implementation has been relocated to `@fluid-internal/client-utils`. There are +In previous releases, the `@fluidframework/tree` package contained an internal events library. The events-related types and interfaces have been moved to +`@fluidframework/core-interfaces`, while the implementation has been relocated to `@fluid-internal/client-utils`. There are no changes to how the events library is used; the relocation simply organizes the library into more appropriate packages. This change should have no impact on developers using the Fluid Framework. diff --git a/.changeset/shy-files-jam.md b/.changeset/shy-files-jam.md index eabca628460e..98979a5286ff 100644 --- a/.changeset/shy-files-jam.md +++ b/.changeset/shy-files-jam.md @@ -5,41 +5,49 @@ "section": feature --- -Presence updates are now batched and throttled +Presence updates are now grouped and throttled Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay. -The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) configuration applies when a Value Manager does not have its own setting. +The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, +enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) +specified during configuration of a [States +Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) +or [Value +Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers) +and/or (2) updated later using the `controls` member of a Workspace or Value Manager. The [States +Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) +configuration applies when a Value Manager does not have its own setting. -Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued. +Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued. Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, -with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous +with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous values set by the client will not be broadcast or seen by other clients. #### Example -You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: +You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: ```ts -// Configure a states workspace +// Create and configure a states workspace const stateWorkspace = presence.getStates("app:v1states", { // This value manager has an allowable latency of 100ms. position: Latest({ x: 0, y: 0 }, { allowableUpdateLatencyMs: 100 }), - // This value manager uses the workspace default. + // This value manager uses the workspace default allowable latency of 60ms. count: Latest({ num: 0 }), }, - // Specify the default for all value managers in this workspace to 200ms, + // Set the default allowable latency for all value managers in this workspace to 200ms, // overriding the default value of 60ms. { allowableUpdateLatencyMs: 200 } ); -// Temporarily set count updates to send as soon as possible +// Temporarily set count updates to send as soon as possible. const countState = stateWorkspace.props.count; countState.controls.allowableUpdateLatencyMs = 0; countState.local = { num: 5000 }; -// Reset the update latency to the workspace default +// Reset the update latency to the workspace default of 60ms. countState.controls.allowableUpdateLatencyMs = undefined; ``` diff --git a/RELEASE_NOTES/2.11.0.md b/RELEASE_NOTES/2.11.0.md index c72e69175e2e..0ed9884158e7 100644 --- a/RELEASE_NOTES/2.11.0.md +++ b/RELEASE_NOTES/2.11.0.md @@ -7,13 +7,12 @@ - [✨ New Features](#-new-features) - [Synchronous Child Datastore Creation (#23143)](#synchronous-child-datastore-creation-23143) - [Presence-related events now support the `off` event deregistration pattern (#23196)](#presence-related-events-now-support-the-off-event-deregistration-pattern-23196) - - [Presence updates are now batched and throttled (#23075)](#presence-updates-are-now-batched-and-throttled-23075) + - [Presence updates are now grouped and throttled (#23075)](#presence-updates-are-now-grouped-and-throttled-23075) - [🌳 SharedTree DDS Changes](#-sharedtree-dds-changes) - [Providing unused properties in object literals for building empty ObjectNodes no longer compiles (#23162)](#providing-unused-properties-in-object-literals-for-building-empty-objectnodes-no-longer-compiles-23162) - [Revertible objects can now be cloned using `RevertibleAlpha.clone()` (#23044)](#revertible-objects-can-now-be-cloned-using-revertiblealphaclone-23044) - [Other Changes](#other-changes) - [API clarifications for devtools packages (#23165)](#api-clarifications-for-devtools-packages-23165) - - [The events library has been moved from the tree package (#23141)](#the-events-library-has-been-moved-from-the-tree-package-23141) ## ✨ New Features @@ -101,41 +100,41 @@ Affected packages: [⬆️ Table of contents](#contents) -### Presence updates are now batched and throttled ([#23075](https://github.com/microsoft/FluidFramework/issues/23075)) +### Presence updates are now grouped and throttled ([#23075](https://github.com/microsoft/FluidFramework/issues/23075)) Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay. -The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) configuration applies when a Value Manager does not have its own setting. +The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers) and/or (2) updated later using the `controls` member of a Workspace or Value Manager. The [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) configuration applies when a Value Manager does not have its own setting. -Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued. +Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued. -Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous values set by the client will not be broadcast or seen by other clients. +Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous values set by the client will not be broadcast or seen by other clients. #### Example -You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: +You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: ```ts -// Configure a states workspace +// Create and configure a states workspace const stateWorkspace = presence.getStates( "app:v1states", { // This value manager has an allowable latency of 100ms. position: Latest({ x: 0, y: 0 }, { allowableUpdateLatencyMs: 100 }), - // This value manager uses the workspace default. + // This value manager uses the workspace default allowable latency of 60ms. count: Latest({ num: 0 }), }, - // Specify the default for all value managers in this workspace to 200ms, + // Set the default allowable latency for all value managers in this workspace to 200ms, // overriding the default value of 60ms. { allowableUpdateLatencyMs: 200 }, ); -// Temporarily set count updates to send as soon as possible +// Temporarily set count updates to send as soon as possible. const countState = stateWorkspace.props.count; countState.controls.allowableUpdateLatencyMs = 0; countState.local = { num: 5000 }; -// Reset the update latency to the workspace default +// Reset the update latency to the workspace default of 60ms. countState.controls.allowableUpdateLatencyMs = undefined; ``` @@ -214,21 +213,6 @@ Affected packages: [⬆️ Table of contents](#contents) -### The events library has been moved from the tree package ([#23141](https://github.com/microsoft/FluidFramework/issues/23141)) - -The tree package contains an events library. The events library's types and interfaces have been moved to `@fluidframework/core-interfaces`, while its implementation has been relocated to `@fluid-internal/client-utils`. There are no changes to how the events library is used; the relocation simply organizes the library into more appropriate packages. This change should have no impact on developers using the Fluid Framework. - -#### Change details - -Commit: [`cae07b5`](https://github.com/microsoft/FluidFramework/commit/cae07b5c8c7904184b5fbf8c677f302da19cc697) - -Affected packages: - -- @fluidframework/core-interfaces -- @fluidframework/tree - -[⬆️ Table of contents](#contents) - ### 🛠️ Start Building Today! Please continue to engage with us on GitHub [Discussion](https://github.com/microsoft/FluidFramework/discussions) and [Issue](https://github.com/microsoft/FluidFramework/issues) pages as you adopt Fluid Framework! diff --git a/packages/framework/presence/README.md b/packages/framework/presence/README.md index 7c608267719e..57da5f634269 100644 --- a/packages/framework/presence/README.md +++ b/packages/framework/presence/README.md @@ -128,21 +128,21 @@ Notifications API is partially implemented. All messages are always broadcast ev Notifications are fundamentally unreliable at this time as there are no built-in acknowledgements nor retained state. To prevent most common loss of notifications, always check for connection before sending. -### Throttling/batching +### Throttling/grouping Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay. -The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](#states-workspace) or [Value Manager](#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](#states-workspace) configuration applies when a Value Manager does not have its own setting. +The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](#states-workspace) or [Value Manager](#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](#states-workspace) configuration applies when a Value Manager does not have its own setting. -Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued. +Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued. Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, -with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous +with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous values set by the client will not be broadcast or seen by other clients. #### Example -You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: +You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example: ```ts // Configure a states workspace