...
Participant’s roles and commitments
Development process
- Define scope
Review of collected use cases and requirements
Define timeline and milestones (what can be accomplished and when)
Attendees
- Randall Floyd
- Will Cowan
- William G. Cowan
- Andrew Woods
- Bethany Seeger
- Brad Spry
- John Rees
- Aaron Birkland
- Yinlin Chen
- Don Brower
- Nick Ruest...
Agenda
Introduction and review of existing design discussionsmeeting goals
Roles and Commitmentscommitments
Identify Stakeholders, Designers, Developers
Development Process(es)processes
Sprint -based? Two-weeks in length? For design and development?cycles and duration
Communication modes
- Process for
- consensus on use cases, scope, and requirements
High-level design and implementation discussion
- Review of existing design discussions
Likely use of API Extension Architecture
Mediated asynchronous services vs. pluggable storage
- Review of existing design discussions
Review
Do we vote on them?
Prioritize them in some way?
Discuss existing use cases
Are they adequately described?
Do we have all the use cases we need or want? Are there more?
- Discussion of scope
- Timelines and milestones
...
- 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
Sidebar: Randy asks if perhaps Brad Spry has already done some of this plumbing with S3?
Brad Spry: Yes, in F3 for datastreamStore, by mounting S3 to Linux filesystem using YAS3FS. datastreamStore's I/O characteristics are asynch friendly. I/O transactions/characteristics are too fast for F3 objectStore and resourceIndex. Performance gains could be had if Fedora's read/write block sizes could be fine tuned, for example from 4k to 128k for datastreamStore. Matter–issue is how to fine tune Fedora in this regard.
More Info: UNC Charlotte's Islandora Deployment and System Schematic
7. Timelines and milestones
- Expectation is no development sprints until 2016
- Also have potential dependency on API-X development schedule
Meeting schedule: every two weeks, same day/time, to keep the ball rolling
Complete action items from #5 by next meeting.