Technical Working Group

• Ben Armintor - Columbia University
• Chris Beer - Stanford University
• Esme Cowles - University of California, San Diego
• Dan Davis - Smithsonian Institute
• Declan Fleming - University of California San Diego
• Neil Jefferies - Oxford University
• Adam Soroka - University of Virginia
• Andrew Woods - DuraSpace - Technical Team Lead
• Zhiwu Xie - Virginia Tech

Work in progress

• Review of top-level architecture
• Collecting of usecase-based performance goals
• Collecting of to-date performance tests

Areas of assessment

1. REST API
   • Are immediate updates required?
   • We should version the API independently
     1. This offers multiple backend implementations/optimizations
     2. A. Soroka: I think this requires a stronger definition of the API than currently exists in the form of user documentation. I suggest defining the API as ontology extensions to LDP.
     3. Clarifying and publicizing (formally and informally) the relationship between the Fedora API and LDP.
2. Performance
   1. Read
   2. Writes
      1. Many small files
      2. Large files
      3. High throughput
   3. Scalable serialization to disk
      • Need to measure scale of load that async serialization can meet
      • Need to clarify async approaches: messaging and sequencers
   4. Replication of objects to another repository instance
   5. Full re-indexing
   6. Full integrity checks
3. Multi-node / Clustered configurations
   1. High availability
   2. Bulk ingest
   3. High read loads
   • Note: generally need to define what clustering provides
4. ModeShape
   1. Assess persistence approach (i.e. bit-level object and datastream persistence)
      1. Some backup/restore details: Backup and Restore
5. Evolution-capability - The system permits graceful (incremental) changes without having to perform replacement of large parts of the system in one step
   
   1. The software permits the graceful replacement of old technology with new technology
   2. The software permits the integration of new technology gracefully
   3. New content formats can be added easily, and the system permits gracefully delivering new representations for existing content
   4. New capabilities can be added or old ones replaced gracefully
   5. Underlying hardware and software infrastructures can be replaced gracefully, and the system can use advances in technology or special characteristics of its technical infrastructure without changing the core Fedora software
6. Ability to use in various integration patterns
7. Storage Options
   1. Tier-storage
   2. Others . . .
8. Preservation-worthiness

Meetings

• 2014-08-13 - Fedora Technical WG Meeting
• 2014-08-20 - Fedora Technical WG Meeting
• 2014-08-27 - Fedora Technical WG Meeting