Coweb Governance Switching

opencoweb / coweb

Open Cooperative Web Framework

Other

233 stars 29 forks source link

Coweb Governance Switching #13

Open vinomaster opened 13 years ago

vinomaster commented 13 years ago

Enhance Coweb API to support the ability to govern which users can broadcast events. When this support is toggled off all users (default) are allowed to broadcast. Otherwise, specific users are granted broadcast ability. All users get to see all events.

parente commented 13 years ago

Making my notes public:

server blocking sync events
late join after editing power restored
gui overlay to prevent clicks on certain widgets
blocked when late joining

parente commented 13 years ago

Discussed this with Brian. We should review for importance knowing that it would be very useful for COPD app. Thoughts on design:

JS APIs for requesting / relinquishing control
Server hooks for controlling who can gain control
Op engine continues running to allow M editors and N viewers
Some decision about what can pass through even when moderated. For example, users should still be able to start / stop their own video in an app, even when they're not moderators. Which events is probably app specific. Maybe a JS API indicating which sync topics are allowed and which are moderated?

parente commented 13 years ago

Can we not run op engine at viewer sites and have them take the last context vector from the last moderator to relinquish control to seed the context vector table for all sites as they all become editors again?

This is key to scaling.

parente commented 13 years ago

Picking up where we left off. We need to start simple. Brian and I discussed simple as meaning:

The session is moderated or not from the get-go. Changing from moderated to non-moderated during the session introduces a good deal of complication with the op engine.
Only moderators are updaters. This can impact performance but keeps the server logic clean for now where non-moderators just get empty state until a moderator joins.

vinomaster commented 12 years ago

On behalf of AliceZhang: There is a requirement to provide a mechanism to support 1 editor - m readers/observers scenario more efficiently, ie, do not store those events and do not go through OT engine.

AliceZhang commented 12 years ago

For the 1 editor - n viewer case, it is easy to achieve the user experience by an application client, ie, the application client for a viewer will not send out any sync event. What we want to verify is that the approach/implementation you have meet the following requirements:

Reduce memory and execution time spent by the coweb OT engine as much as possible for 1-n case (with comparison to directly using cometD)
Switch to n editors - m viewers mode easily

Thanks.

vinomaster commented 12 years ago

Current understanding is this is a optimization wish-list item, but not a hard requirement by Alice. Moving to next planned release.