SVE Revisions (Early Discussions)

As we develop the SVE and the client API we try to re-visit and to re-evaluate some of the design choices we made along the way. Right now we are reviewing the callback mechanism.

CALLBACKS
Current implementation:
callbacks are registered during subscribe.
When an update is received the deliver thread calls the callback function with the updated value as argument. We discussed adding a reference to the (updated) SV object to the argument list but that's currently not implemented.
In the not guaranteed case the deliver thread updates sv.value and sets the sv.isUpdated event (flag).
In the guaranteed case the new value is appended to the value queue. Currently isUpdated is not set in this case.
Other relevant attributes (e.g. update time, maybe a future exposure number) are set in the attribute list of the sv object but are not buffered in the value queue. Hence a callback function is not guaranteed that, for example, sv.timestamp reflects the time of the update currently been handled by the callback (it could have already been overwritten by a later update).
Also, there is a possibility the the (Python) schedule executed pending callbacks not in sequential order - if that happens updates may be processed in an incorrect order.

Possible Solutions
Value Queue
change from a single value to a tuple to buffer all relevant information for this update (value, time, exposure number) [currently being implemented]

Callback
We remove the value argument and replace it with a reference to the sv object. Now callbacks are all the same and it doesn't matter which order the scheduler chooses. However, we have to instruct the application programmer that the first thing he needs to do in his callback function is to call sv.read to get the updated value. It's recommended to use the optional flags argument in the read call to receive the flags dictionary which will contain the additional information from the value queue (update time, exposure number) [currently being implemented]


EXPOSURE NUMBER
Another topic of continous discussion is the exposure number. Many SV's will have to be synchronized with the exposure number. The exposure number will be published by a component of the OCS. If we are not observing the exposure number is set to None.
If "select by exposure number" is only needed for offline analysis one could design the DB server code such that it subscribe to the exposure number and appropriately links the underlying DB tables. Another solution that works on and offline is to add some functionality to the SVE engine itself. If we are willing to single out exposure number as a special variable we could instruct the SVE to subscribe to the published exposure number and to add the current value as an attribute much like the timestamp to each update. That way EVERY SV would be synchronized to the correct exposure number.