-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The timing object spec defines the following event types:
- change
- readystatechange
- timeupdate
- error
There are still other state changes that may not be reflected by these event types.
For example, if access restrictions (see issue #21) are changed from "rw" to "ro", e.g. due to credentials timing out, the application might need to know about this. Or, if a timing converter (see issue #13) is modified so that it has a new parent (.timingsrc), it will need to reflect the properties of its new parent (e.g. range or access) instead of the properties of its previous parent.
Maybe there should be an extra event expressing state changes other than vector changes? I still think the change event is special and I don't think it would be a good idea to abuse this for the communication of other types of state changes.