build(client): publish experimental presence #22499
Conversation
jason-ha
commented
Sep 13, 2024
•
jason-ha
commented
- Note current Notifications limitation
- Connect docs to readme with more details
github-actions
bot
added
area: framework
⯅ @fluid-example/bundle-size-tests: +245 Bytes
Baseline commit: 709f085 |
tylerbutler
added
the
release-blocking
|
I think you might need a PR description to make to make CI happy. |
|
If you want customers to try this out, then you should probably include a changeset so it will be announced in the release notes. |
Yep - that was actually intentional because there are two changes that should happen first. Wanted this one filed for tracking release cut. :) |
|
|
||
| Experimental Presence package added | ||
|
|
||
| **[@fluid-experimental/presence](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#readme)** is now available for investigation. The new package is meant to support presence of collaborators connected to the same container. Use this library to quickly share simple, non-persisted data among all clients or send/receive fire and forget notifications. |
There was a problem hiding this comment.
I'm not up to date with the exact capabilities of experimental presence, so I read the README, and wanted to confirm if the "quickly share simple, non-persisted data among all clients" has guaranteed delivery so all clients (eventually) agree on that state? Based on my little knowledge about experimental presence, I had it very tied to signals and non-guaranteed delivery. If that were the case, I'd suggest making it more explicit in the changeset, but I suspect that's just my outdated understanding.
There was a problem hiding this comment.
Good note to have. I'm adding reliability notes to readme. I think we are not quite as bad as fully unreliable as we think we isolated the most common drop situation and have done some accounting.
| @@ -82,6 +82,11 @@ presence.getStates("app:v1states", { myState2: Latest({x: true})}); | |||
| would be compatible with both of the prior schemas as "myState2" is a different name. Though in this situation none of the different clients would be able to observe each other. | |||
|
|
|||
|
|
|||
| ### Notifications | |||
|
|
|||
| Notifications API is not well connected. All messages are always broadcast even if `unicast` API is used and all are emitted as `unattendedNotification` event rather than the appropriate custom event. | |||
There was a problem hiding this comment.
I might suggest dropping the first sentence. For a while I couldn't quite make sense of it even in the context of the second one, and I think the second one on its own is clear about the limitation.
