You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To ease reproducibility, OpHistoryServices should be able to persist their histories, and from that persisted data be able to restore that history into a readable form.
Ideally, this would be accomplished using some OpHistoryService API along the lines of:
(One) implementation of these methods might benefit from scijava-persist
The restoration of a history would ideally be possible independent of original OpHistoryService implementation (i.e. a FooOpHistoryService should be able to restore a BarOpHistoryService), but this might be too strict an approach. Potential problems may include:
Situations where aa BarOpHistoryService doesn't have all of the Ops listed in the history created by the FooOpHistoryService that recorded the history
Limitations on extensibility (all OpHistoryServices would have to serialize/deserialize in the same way, or at least know how to deserialize numerous types of serialized histories)
One interesting thought: upon a call to restoreHistory, should the OpHistoryService:
Erase/Record any previously logged history?
Meld its previously recorded history with the history recorded at inputLocation?
Do we want to be able to reproduce an Op execution path in a super environment of that which it ran initially (e.g. an updated Fiji with more update sites)?
Do we want to have human-readable record of how a particular output was created by Ops?
Currently, OpHistory is kind of in the middle of both of these requirements without satisfying either. To resolve this issue we need to agree which of these requirements we will adopt in Ops, if any, and then lay out an implementation plan.
Activity
hinerm commentedon Sep 26, 2023
Two fundamental questions here:
Currently, OpHistory is kind of in the middle of both of these requirements without satisfying either. To resolve this issue we need to agree which of these requirements we will adopt in Ops, if any, and then lay out an implementation plan.
Merge pull request #66 from scijava/imagej/imagej-ops2/null-op-descri…