- Refactored command structure to move XNAT-y stuff off to the back-end part of the command to make it a bit more independent.
- Figure out way to break out translating XNAT object models into a more general model.
- Use Google Autovalue library to generate models to work with.
- Working on project configuration for container services. Adding a wrapper around config service to store and work with commands.
- Putting out fires, no work on event services.
Verb is operation:
- User request (e.g. user searches for sessions and wants to launch some process on the results)
Noun is event target:
Identified by some criteria: ID and data type with hierarchy,1
data types, etc.
- Actor data: user who made the event happen, for example, maybe other info about the event context. These could be in a map of attributes on the event, event acceptance can be calculated based on matching one or more attributes.
Each event will have a payload. How are these defined?
Many "events" aren't discrete points in time, so events also require status: started, completed, failed, etc. Unlike workflows, these aren't persisted as a unique timeline. We may need some way to associate events across an entire operation, but we can revisit later.
Definition of the noun will depend on the particular operation and context and would be defined in the event itself.
Event responders would be the way to wire to a data event. The basic event responder interface would indicate whether an event should be accepted and something about the event payload. Different base implementations for, e.g., handling events by data type, by other attributes.
This really is IFTTT.
An API to get sample events.
The data type hierarchy is the full stack of inheritance. For example, an MR session is:
You could say you want an xnat:mrSessionData or an xnat:experimentData and the MR session would match either one.