Editor - Data Engine communication model

[amis92]

• There are two models in the Editor: Roster model and Option Simulation.
• Roster model is a representation of actual roster content - selections made by the user.
• Option Simulation is a representation of all possible options for a given roster node, and contains the information about what is already part of the roster (e.g. selection count).
• Simulated View: ghost-selection so that you can browse an unselected entry, what options does it have, and go deeper.
• Roster diagnostics - a list of warnings/errors pointing to some locations in the roster model and/or provided Option Simulation.

A virtual REST API a Data Engine would provide:

• GET /rosters/{rosterId} - returns Roster Model
• GET /simulations/{rosterId}/{rosterNodeId} - returns an Option Simulation for a given roster node
• POST /rosters/{rosterId}/add - input: node from OptionSimulation.
• POST /rosters/{rosterId}/duplicate - input: node from Roster Model, potentially with the count of how many duplicates to create.
• DELETE /rosters/{rosterId}/nodes/{rosterNodeId} - input: node from Roster Model.
• PUT /rosters/{rosterId}/nodes/{rosterNodeId}/count - input: new node count.
• GET /rosters/{rosterId}/diagnostics - returns a list of warnings, errors and messages etc.

[jlueck6]

Would /diagnostics need to be called each time after modifying the roster? Petition to have (rosterDelta, rosterWarnings) or similar be the return of any API call modifying the roster (or maybe that is the idea and it isn't captured here yet).
Where rosterWarnings could be a delta where each warning has an ID, so the engine can just pass an initial warningMessage[] {warningId, nodeId, clear?:false} when a validation issue occurs, then follow up later when the warning is fixed {warningId, clear:true} either in the first array or a clearedWarnings[] that just holds IDs
Or, maybe we just keep the GUI stateless as possible and pass it all each time

[amis92]

Well, the example is mostly illustrative as to what an API shape would be, so things like that are up for discussion. We can say that things are immutable: single rosterId means a single state of a roster. Any changes result in a new rosterId that has the updated state. If we do so, then it'd be up to UI when to retrieve the updated warnings, etc. I think that we should generally start from immutable state with full new state sets, and then when we tune performance we can consider calculating patches and deltas. :)

[jlueck6]

True- no need to get into deltas when the test sets are going to start simple, and it remains TBD if immutable becomes a problem at 100 roster entries or 10,000.

I would still argue roster warnings are a part of roster state, but that's also not important now and easy to add into the API if we want it

[amis92]

In terms of actual Data Engine implementation I was planning on - yes, the diagnostics are an essential part of "compilation" result and would be computed as part of analyzing the roster. Whether they'd be retrieved together or separately (the roster model vs diagnostic list) would be essentially up to the consumer. You could even imagine adding just a count of diagnostics to the roster model and leaving decision whether to retrieve or not up to the UI. Adding diagnostic count to the roster nodes, signaling which have issues, and allowing UI to only retrieve diagnostics for a given node. Many possibilities.