...
- Ensure that all resources are checked every n months
- Run continual fixity checks
- Only alert me there failures
- Call an arbitrary HTTP endpoint on success and/or failure
- Send a (jms,stomp) message to a endpoint on success and/or failure
- Perform fixity check on HEAD version of resource only
- Perform fixity check on all versions of resource
- Generate list of resources checked since X date
- Generate list of resources not checked X date
- Generate a fixity audit report by resource
- Generate a csv of fixity audit results showing resource id, date checked, checksum, and the result
- Set rate limits (max bits/second) for checks
- Allow checks to be scaled horizontally
- Store fixity results in external datastore
- triplestore
- sql database
- no-sql db
- Deliver fixity requests in batches
Components
Fixity Checker
- performs the fixity check on a resource and communicates the results to the configured Fixity Result Handler
Fixity Result Handler
- responsible for storing the results. I can imagine difference implementations that talk to different types of data storage backends
Fixity Result Reporter
a service that generates reports Reporter - an interface for generating report.