Page History

...

1. Round table of intros
2. Roles and commitments
   1. IU (Randall and William) committed to lead and provide significant developer time
   2. UNC-Charlotte (Brad) stakeholder, QA over AWS testing
   3. Duraspace (Andrew) wrangler/encourager, feedback offeror
   4. NLM (Rees) stakeholder/lurker, contribute case studies
   5. Notre dame (Don) stakeholder, contribute use cases, perhaps some developer time
   6. Va Tech (Yinlin) stakeholder, cold storage use case, AWS testing
   7. Nick R. (role with Ontario cloud service) –stakeholder, tester, perhaps some development
   8. 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.
3. Process
   1. Assume work will progress under an Agile framework, with development sprints
   2. still need significant time to gain a shared understanding before scheduling any work
   3. expect user stories/context and development work will progress asynchronously
4. High-level design
   1. Existing use cases/design discussions -- are old but still hold relevance and resonate for many at a high level
   2. 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
      1. Woods emphasizes F4's slim code core philosophy
      2. 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
   3. 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
5. Use cases
   1. Aaron–API-X experience demonstrated that use cases generally need some common structure and better task/outcome definitions to properly generate evaluation criteria
   2. Action items:
      1. Randall will look at API-X templates as inspiration to create some for this group
      2. 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 has already done some of this plumbing with S3?

Brad: yes, in F3 for datastreams, but other data types need other tools. Employs S3fs FUSE -- mounts Linux filesystem to S3 buckets https://github.com/s3fs-fuse/s3fs-fuse.

Some I/O transactions too fast, such as with triplestore. Block sizes matter–issue is how to fine tune Fedora in this regard

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.