While creating stream_resources() in historian.py, the questions arose of whether a user's call to .get() on a resource should trigger a resource update for stream_resources(). Further, the question of whether a resource.get() should trigger handle_internal_event() at all should be considered.
The rational here is that stream_resources() yields a current screenshot of available workflow resources to the caller (user wanting to see available resources) anytime there is an "update" to the resources. A user purely reading the value of a resource ought not to trigger a resource update, and therefore a yield of a new resource screenshot, when the resources haven't changed at all.
One solution to this problem would be to change the resources in external.py to not trigger handle_internal_event() on a call to get(). This may be a robust and problematic fix. However, the implications should be considered in dealing with this problem.
While creating
stream_resources()inhistorian.py, the questions arose of whether a user's call to .get() on a resource should trigger a resource update forstream_resources(). Further, the question of whether aresource.get()should triggerhandle_internal_event()at all should be considered.The rational here is that
stream_resources()yields a current screenshot of available workflow resources to the caller (user wanting to see available resources) anytime there is an "update" to the resources. A user purely reading the value of a resource ought not to trigger a resource update, and therefore a yield of a new resource screenshot, when the resources haven't changed at all.One solution to this problem would be to change the resources in
external.pyto not triggerhandle_internal_event()on a call toget(). This may be a robust and problematic fix. However, the implications should be considered in dealing with this problem.