Design interface coupling for History

[jamienoss]

The existing interface of having get and set funcs seems complete for what this is.

Possible API additions:

• last() (or equivalent) but this depends on the data type being used under the hood as this may already have "last" functionality. However, this may still be desirable to directly expose to the API layer.

The main question is how this couples with other interfaces, how is it used?

Questions:

• Add this to evolver.base? (not doing so could introduce circular imports, we'll have to see...)
• Make attr of evolver.BaseInterface?
• What is the interface? Is there a clean opportunity to bake this under the hood, i.e., in Device.set() & Device.get()?
• Make this mostly a decorator pattern, e.g., see above point about Device set| get. I think this would work quite elegantly - that funcs needing to be recorded in the history, simply get decorated. Could add an arg to spec whether the input or output (or both) get recorded.
• ...

[jamienoss]

@amitschang thoughts?

[amitschang]

I don't see a particular reason to change the behavior - at the moment - that the manager (Evolver) holds the history server and puts read values from devices. I see two main uses of history as a consumer:

• The webUI for plotting, where there is an api endpoint that calls get with some input query
• The controllers body in case they don't want to buffer themselves, they will have access to the box and thus history so can call it similar to calling get on a device.

[jamienoss]

The webUI for plotting, where there is an api endpoint that calls get with some input query

The get functionality can wait to be properly ironed out, unless we start to need it for restarting from old state, but that too can probably be punted down the road.

The controllers body in case they don't want to buffer themselves, they will have access to the box and thus history so can call it similar to calling get on a device.

This part I'm not so convinced of. For better encapsulation and extensibility, I don't think we should hardwire the requirement that a manager be needed to use a device that has code that sets history. The evolver/manager can store the history, however, my question above is how do the devices couple/interface with the history, and do so directly.

so can call it similar to calling get on a device.

I think this is the crux of my point, yep they can, however, we don't necessarily want to require users to have to re-implement a device's interaction with the history, just because they don't want to use the manager. I don't think the evolver/manager should be the device interface with "history" - which, I think, is effectively what you're saying.

So, the more one aspect of the SDK can work in isolation from the rest, the less susceptible it'll be to getting pretzeled.

Let's chat about this a tad today, it would be good to at least get an idea of how we separate history streams etc, as this may require some args to set that would be better thought out now. We may also need to consider something similar to logging.getLogger()?

[jamienoss]

Another good point, though semi-trivial, I think it would be more intuitive and canonical if we use set instead of put.