- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Feb 2016 10:58:25 +0000
- To: public-webtiming@w3.org
ingararntzen has just created a new issue for https://github.com/webtiming/timingobject: == Access restrictions for timing objects == 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". Please view or discuss this issue at https://github.com/webtiming/timingobject/issues/21 using your GitHub account
Received on Wednesday, 24 February 2016 10:58:28 UTC