...

• Andrew Woods
• Esme Cowles
• Chris Beer
• Daniel DavisDavis 
• Declan Fleming
• A. Soroka
• Benjamin Armintor
• Zhiwu Xie
• Neil Jefferies
• Yinlin Chen

...

1. Clarify objectives of this group (reference: charter)
2. Establish approach for addressing initial objectives
   1. Validate components and APIs
   2. Identify any questions or concerns about Fedora 4.0 architecture in the context of the project’s goals, objectives, and use cases
   3. Assess core vs. modular features
3. Thought exercise: what would be the technical "risks" of releasing 4.0 Production *now*?

Minutes

Notes for Aug 14 Meeting:

Discussion

Group objectives 

...

1. Help figure out if Fedora 4 (as developed) is meeting user requirements

    

   Separate out REST API from remaining Fedora Implementation

   Permits other implementations (different optimizations)

    

   Clustered Multiple Node Case (Neil)

    

   Performance

   “Things are not working the way I like it to”

   “Cannot meet a specific performance requirement”

   “Can it support increased ingest performance”

    

   Process for identifying the tasks. (Chris)

    

   Review:

   What are the aspects of the need to be reviewed:

    

   API - REST, maybe core classes

   Reviewing the architecture.

   Performance (lay out scenarios cross by parts of architecture)

    

   Use Cases (Scenarios)

   Functional Requirements (features, capabilities)

   Non-functional Requirements (ilities - like scalability, extensibility)

   Functional Architecture

   Technical Architecture (products and technology)

   Implementation

    

   Trace asynchronicity (against requirement a.k.a goals)

   Trace preservation-related requirements and capabilities

       - Modeshape metadata and ramifications

    

   Read or Write more important

    

   Note - People are at different levels

   Modeshape

   Object persistence

   Asynchronous model for persisting (more well known)

   Less so for asynchronous check that functions were performed (possibly not part of repository)

   Two asynchronous processes in play

    

   Summary Actions:

    

   ...

   1. 1. i.e. Ensure F4 platform is situated to address community needs going forward
   2. Summarize group's findings in a report
      • Note: term 3-months, mid-Aug - mid-Oct
      • Note2: it would be nice to have some tech continuity in making decisions

   Approach

   Items for team assessment

   1. REST API
      • Are immediate updates required?
      • We should version the API independently
        1. This offers multiple backend implementations/optimizations
   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)
   5. Preservation-worthiness

   Actions

   For next week

   1.  All: bring expectations and goals (grounded in production use cases)
      • Not just performance but all qualities/functions
      • ... Goals that improve upon Fedora 3
      • ... And/Or goals that were supported by Fedora 3 and still need to be supported by Fedora 4

   ...

   2.  Esmé: update architecture diagram
   3.  Andrew: bring summary of performance tests/results to-date

   Ongoing

   1. Compare F3 and F4 ingest rates
   2. Revisit basic principles: "Why repository? Why Fedora?"

   ...