...
- Design document was presented and discussed, Nick Reid wasn't able to attend this call so we'll look forward to him leading us on UI extension in a later call.
The overall structure was understood. There was questions on:
Question Response/Resources Complexity of utilizing this architecture, especially in deploying new services (also perhaps cost of ownership?) It's not in question weather approaches to building extensible software can introduce complexity. That always seems to be the case. We all know why we need to be extensible so the approach is to manage complexity as much as possible. To that end we do plan on providing examples as well as starting points along with documentation (here and read the docs). It's something that's on-going though so maybe the committee needs to walk through some of this and identify gaps that they see. Why would an extension mechanism not already exist by the time an implementer needs to use them? The Document presumes that not every extension mechanism would exist before an implementer would want to extend an existing concept (due to cost, difficulty forecasting, etc). It covers therefore the process of the community adding the mechanisms. It should be noted that anyone in an open source project can add an approved mechanism to any concept, and that the code stewards would always approve it. What happens to the original Requisition? When the split requisitions are fulfilled are they aggregated back to the original? The original requisition is never converted into an order. In this analysis it's proposed that it ends in a status named "split". The facility would see the two split requisitions, A1 and A2, that are filed on its behalf after that.
As for fulfillment the scenario doesn't dive into much depth here yet (outstanding questions) and so I filled in that the two Order's from their respective Requisitions would end up as seperate separate PoD's. This makes sense to me as fulfillment would progress independently for each and so we can't presume to know which will be fulfilled and received in any order. This is chalked in lightly though as the scenario would need to add more detail for us to tackle the fulfillment side of things.
...