Time/Place 

• Join fedora-project.slack.com on the "tech" channel

• Self-register at: http://slack.fcrepo.org/

Attendees 

1. Danny Bernstein   (note taker)
2. Peter Winckles  
3. Michael Ritter 
4. Demian Katz  
5. Geoff Scholl 
6. Joshua Westgard
7. Mark Jordan  
8. Arran Griffith 

Agenda

1. Desired Features
2. Review Existing Solutions
   1. UMD
      1. Features
      2. Scalability
      3. Limitations
   2. RipRap
      1. Features
      2. Scalability
      3. Limitations
   3. Camel Toolbox
      1. Features 
      2. Scalability
      3. Limitations
3. To extend or to roll anew
4. Availability over this quarter

Notes

Riprap Mode: 

• started in 2018.  Islandora 2 was just getting going.  Responding to limitations of Islandora’s fixity checking capabilities (repo bloat)
• cron basis, get a list  of resources, check with last recorded in database.
• designed with wider user case in mind ( not Islandora only)
• has various plugins for messaging,  pulling resources, etc.
• README contains 
• Symphony framework (PHP) not great - 
• Compliant with PREMIS event and vocabularies
• Scalability:  run multiple instances of Riprap
• Thin Mode  (last success / or failure) - keeps database size down to a minimum.
• Commandline interface and REST for reporting:  returns JSON and CSV
• start and end
• outcome
• offset
• sort  

Demian - suggested using version hardening techniques (using platform  in compose json and avoid * dependencies) for dealing with symphony/php version migration issues. 

UMD - https://github.com/umd-lib/umd-fcrepo-docker/tree/develop/fixity

• starts with cron job to kick off the checking.
• nightly fixity checking window  - avoids putting undue load on Fedora during peak usage times
• uses activemq - originally used camel but moved away and just uses activemq directly
• separate audit triplestore - tracks premis events
• generating the list of candidates was tricky with the bottleneck  (solved with list caching) - not currently using a relational database
• continuous checking model  - everything checked every 6 months or so
• checker is python based
• goes through Fedora API’s fixity checker
• fixity checker sends an event to success or failure queues where they are split into different queues  - write to triple store, send email

Actions:  Mark Jordan  and Joshua Westgard will update the matrix on the desired feature page to clarify what currently exists and what could easily be added to complete the feature set.