When a developer initializes a Live Share DDS that uses LiveObjectSynchronizer (e.g., LiveState), an initial connect message gets sent out to all clients, after which each other client responds with an update with their latest state for each DDS they know about. This is an N^2 behavior for signals, which causes issues in large meetings. In addition, each client periodically sends updates in the background, which is also costly.
Describe the solution you'd like
To control this behavior for scenarios where large meetings are desirable and/or common, we should introduce a setting that allows background events -- including both the state responses coming from incoming connect events and the periodic updates -- to send so that a developer can limit that behavior to one/fewer "presenter(s)". This should not restrict manually setting the state for one of these DDS's, so that something like LiveState could be used to track the current presenter's userId, but any user could then "take control", which the app could then use to flip the flag (e.g., canSendBackgroundUpdates) setting for all pertinent DDS's. This would make it possible to use these DSS's in an N*1, rather than N^2 fashion.
Alternatively, we could figure out how to have this setting be a per-container global setting, so that the developer only has to change it once and not per-DDS. This might be better if we see it as purely a COGS implementation, but perhaps there are reasons developers might want to control which DDS's have this behavior (e.g., only one user is in charge of one LiveState instance, but all users are equal for another).
Describe your user scenario
When a developer initializes a Live Share DDS that uses
LiveObjectSynchronizer(e.g.,LiveState), an initialconnectmessage gets sent out to all clients, after which each other client responds with an update with their latest state for each DDS they know about. This is an N^2 behavior for signals, which causes issues in large meetings. In addition, each client periodically sends updates in the background, which is also costly.Describe the solution you'd like
To control this behavior for scenarios where large meetings are desirable and/or common, we should introduce a setting that allows background events -- including both the state responses coming from incoming
connectevents and the periodic updates -- to send so that a developer can limit that behavior to one/fewer "presenter(s)". This should not restrict manually setting the state for one of these DDS's, so that something likeLiveStatecould be used to track the current presenter'suserId, but any user could then "take control", which the app could then use to flip the flag (e.g.,canSendBackgroundUpdates) setting for all pertinent DDS's. This would make it possible to use these DSS's in an N*1, rather than N^2 fashion.Alternatively, we could figure out how to have this setting be a per-container global setting, so that the developer only has to change it once and not per-DDS. This might be better if we see it as purely a COGS implementation, but perhaps there are reasons developers might want to control which DDS's have this behavior (e.g., only one user is in charge of one
LiveStateinstance, but all users are equal for another).