webtiming / timingobject

Defines the HTML5 Timing object at the basis of multi-device synchronization matters
25 stars 4 forks source link

Access restrictions for timing objects #21

Open ingararntzen opened 8 years ago

ingararntzen commented 8 years ago

Timing objects are objects, and this means it is possible to enforce access restrictions on them. At least, timing objects could be read-only (updates denied) or they could be read-write (updates ok). It would also be possible to imagine more sophisticated schemes such as distinguishing different levels of write access (e.g. acceleration not allowed).

Access restrictions for timing objects are particularly useful for ensuring asymmetric patterns. For instance, a presenter of a distributed media presentation would have read-write access, whereas the audience is restricted to read-only. Timing providers would for instance enforce access restrictions based on login. Private timing objects would be read-write whereas shared timing objects could be read-only. The same pattern would also be present for different components within the same page layout. For instance, UI controls would need read-write access whereas pure viewer components only require read-only.

In any case, it would be helpful if the timing object exposed their access credentials through a property. This way, UI components could be designed to adapt automatically to the capabilities of the timing object. For instance, UI controls could hide or disable play/pause buttons if the timing object is read-only. More generally, application behavior might also change based on access restrictions.

A first proposal could be to add a property .access to the timing provider and the timing object, with string values such as "ro" and "rw".

tidoust commented 8 years ago

I agree that it would be useful to expose a property that tells whether a TimingObject instance is read/write or read-only.

I would suggest to use a readOnly boolean property similar to that used for input fields in HTML: http://w3c.github.io/html/sec-forms.html#elementdef-input

A boolean property will not allow to capture more granular access control rights, but I would not do that unless there is a compelling reason to do so. Timing providers may reject update operations that they do not want to allow for a given user, and applications can implement the logic necessary to prevent such errors from happening in the first place.