Wiring new Beans/Grinders/Equipment APIs data into Workflow API #64

@tadelv This is a thorough design. Great job! A few minor considerations:

• People should be available as pre-shot data too, not just as post-shot annotation. DYE lets user define the barista and drinker on the Next-Shot page.
• As mentioned on other comments, modelling beans blends may be interesting.
• Even without explicit blends, many beans variables could be lists (like variety is), as occasionally single origin bags do mention several regions, farms, or even more than one processing.
• I think it may be useful to force bean elevation to be a numeric list, as eventually querying or analyzing data by elevation could be interesting.
• Will you be keeping profiles full definitions also as snapshots on shots? Important for DYE, which, when recalling a past shot in auto-favorite or manual copying gives the option to use the profile either exactly as was used in the old shot, or use the current version of the profile with the same name.

Thanks @ebengoechea . I'll see how I can accommodate your suggestions. And yes, I am thinking of adding the profile snapshot on the shot record, same as with equipment.

Even though, John and I have a Profile API in mind, that would not use the guuid schema for identifying profiles, I think it's still sensible to keep the profile snapshotted on the record itself.

Decaf and the comments around mixed species/bags look good. I want to reread the whole thing soon.

I've been thinking through what the workflow would look like. I know it will be driven by the the UI experience but wanted to bring it up for your thoughts.

Is the expectations that a user defines a bean first, and then associates it with a bag? Ideally it would be one step but some fields would create the bean record and others would create the bag record. For multiple or subsequent bag purchases, I would expect to clone a previous bag. I dont think I'd do much manual manipulate of the bean record.

Correct! Ideally a user would populate their Bean table and then associate individual BeanBatches with the specific Beans.
The thing is, none of this is enforced by the "Bridge" app. We can go as simple or as complex as needed. At least that's what I (wish to) believe is the case right now: https://github.com/tadelv/reaprime/blob/feature/shot-peripherals-introduction-discussion-%2366/doc/plans/beans-equipment-shot-data-schema-proposal.md#116-skin-complexity-tiers

@ebengoechea , I couldn't help - everything seemed a little over-engineered for 90% of use cases, so I tried to make a simplified approach as well.

https://github.com/tadelv/reaprime/blob/feature/shot-peripherals-introduction-discussion-%2366/doc/plans/simplified-schema-proposal.md

Maybe "simplified" is only in the name. The core difference is that the responsibility for the schema of Eqipment, Water and Taste notes as well as other metadata is deferred to the DYE2 plugin. Bridge app only provides the storage mechanisms, APIs and fields on the WorkflowContext.

I think this improves the separation between simple / advanced usage. Less "mental work" for skin developers and users with simple coffee/equipment management, with an optional, "enable all bells and whistles" mode in the bundled plugin.

Is a compromise like that acceptable for you?

@tadelv Is a compromise like that acceptable for you?

Yes. DYE2 will even support only a subset of the simplified api. No additional beans metadata (beyond the 4 fields on current DYE) or equipment (beyond the grinder details), at least on the first version that Pulak is finishing. Still having those in REA is a big step forward and should allow DYE or other plugins to extend the initial functionallity.

Can't access the file. Next time press y on keyboard to get permalink on GitHub before copying 😉

@miharekar I'm pressing y but it doesn't get anything? :D

https://github.com/tadelv/reaprime/blob/64307e6e700f5e0a4a42f078337701febb2e0aca/doc/plans/archive/simplified-schema/simplified-schema-proposal.md

It did - you have 64307e6 in the url now