Access restrictions for timing objects #21
Description
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".