...
- Design - Asynchronous and Pluggable Storage
- Meeting notes: 2015-08-17 - Indiana - Amherst F4 Storage
- Design - API Extension Architecture
Meeting Notes
- Round table of intros
- Roles and commitments
- IU (Randall and William) committed to lead and provide significant developer time
- UNC-Charlotte (Brad) stakeholder, QA over AWS testing
- Duraspace (Andrew) wrangler/encourager, feedback offeror
- NLM (Rees) stakeholder/lurker, contribute case studies
- Notre dame (Don) stakeholder, contribute use cases, perhaps some developer time
- Va Tech (Yinlin) stakeholder, cold storage use case, AWS testing
- Nick R. (role with Ontario cloud service) –stakeholder, tester, perhaps some development
- Amrherst (Bethany/Aaron) stakeholder, Aaron has a Glacier cold storage interest, not sure about commitment level
General agreement that we'd all like to better understand ties with the API-X effort/group. We should try to cross-pollinate, communicate, understand/identify synergies where they exist, but at a distance, too.
- Process
- Assume work will progress under an Agile framework, with development sprints
- still need significant time to gain a shared understanding before scheduling any work
- expect user stories/context and development work will progress asynchronously
- High-level design
- Existing use cases/design discussions -- are old but still hold relevance and resonate for many at a high level
- API extension architecture – relationship with API-X/F4 extension architecture could be strengthened, but agree it is a suitable framework to start but will likely evolve as requirements emerge
- Woods emphasizes F4's slim code core philosophy
- Why asynch storage not core? Aaron B. some interactions with specific storage options may need more direct integration with F4 core, but other pieces of a plugable API may not; requirement details should start to reveal these divergences
- Mediated services vs. plugable storage – related to API-X. Randall making a distinction between the heavy lifting needed by any storage solution vs. F4 REST services/messaging interactions
- Use cases
- Aaron–API-X experience demonstrated that use cases generally need some common structure and better task/outcome definitions to properly generate evaluation criteria
- Action items:
- Randall will look at API-X templates as inspiration to create some for this group
- Attendees will look at current use cases with a fresh eye to ensure their needs are being met; Woods encourages use of the wiki's 'like' feature for lurkers or the uncommitted so at least your voice is recorded–it matters