Time/Place
- Time: 12:00pm Eastern Daylight Time US (UTC-4)
- Place: Google-hangout, https://plus.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug8
Attendees
- Andrew Woods
- Esme Cowles *
- Chris Beer *
- Daniel Davis *
Declan Fleming- A. Soroka
- Benjamin Armintor
Zhiwu XieNeil Jefferies
Note-taker =
Previous note-taker = *
Agenda
- Thought exercise: "What would be the technical "risks" of releasing 4.0 Production *now*"?
- Or another way, "Where do we want to put next sprint's dev energy"?
Review of previous actions
REST API spec plan: Agreement on approach? Next steps?
- Performance scenarios: Focus on use case numbers from Oxford and Stanford?
- Strawman for Grinder scenarios: Additional Testing Scenarios
- Third highest team priority from survey: "Preservation-worthiness"
Previous Actions
From 2014-08-20
- Neil to define initial set of system CI tests
From 2014-08-27
- Ben and Adam: Begin drafting REST API spec and what a TCK should cover. Incremental deliverable for next week: what LDP is, how F4 extends it, and bytestreams
- Dan: Review existing performance work and put together some scenarios
- Esme: Report on status of filesystem serialization once UCSD beta pilot has progressed - Beta Pilot page has been updated with deliverables
Discussion
Adam begins with API:
Base specification LDP plus base ontology but bytestreams
Possibly add transactions (suitable for web scale, not XA, JCR spec)
Thoughts about container:
Objects plus datastreams (fedora)
External to repo
Esme: other objects in repo
Andrew: question do we want to support
Adam: has different guarantees if outside
Adam: Need to think out ramifications for different kinds of outside items
Dan: Could have some overlap with issues about tiered storage
Adam: Not absolutely required for LDP
Andrew: Member, Reference, Indirect Container (need definitions)
Dan: Considerations of asynchronous responses (overlaps burden for remote operations)
Andrew: Need to define proposal for tiers
Adam: Keep core simplest possible
Andrew: We need to review what we have, LDP, is the interaction model logical, clean, does it represent what we expect out of the repository
Adam: Did we make a good guess for the implementation? Test on real world usage.
Adam, Andrew: Specification with dependencies for transactions, versioning, locking, etc.
Andrew to Adam: Can you flesh out all the tiers?
Adam: Will try for week from today
Esme: Should conversation be on Fedora tech list
All: yes
Performance Scenarios (Dan)
- Fixity checking
- Real-world scenarios
- Cache and no-Cache
- Look at direct REST client for Python
- Setting up environment (Scott Prater may have done some work)
- Many folks could contribute tests
RDF and Sparql Update well underway for next period (Esme)
- Adam to detail proposed tiers of API
- Dan to create matrix of performance test payloads (probably here)
- All to review "Preservation Worthiness" description for next week's discussion