...
- REST API
- Are immediate updates required?
- We should version the API independently
- This offers multiple backend implementations/optimizations
- 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.
- Clarifying and publicizing (formally and informally) the relationship between the Fedora API and LDP.
- Performance
- Read
- Writes
- Many small files
- Large files
- High throughput
- Scalable serialization to disk
- Need to measure scale of load that async serialization can meet
- Need to clarify async approaches: messaging and sequencers
- Replication of objects to another repository instance
- Full re-indexing
- Full integrity checks
- Multi-node / Clustered configurations
- High availability
- Bulk ingest
- High read loads
- Note: generally need to define what clustering provides
- ModeShape
- Assess persistence approach (i.e. bit-level object and datastream persistence)
- Some backup/restore details: Backup and Restore
- Assess persistence approach (i.e. bit-level object and datastream persistence)
- Evolution-capability - The system permits graceful (incremental) changes without having to perform replacement of large parts of the system in one step
- The software permits the graceful replacement of old technology with new technology
- The software permits the integration of new technology gracefully
- New content formats can be added easily, and the system permits gracefully delivering new representations for existing content
- New capabilities can be added or old ones replaced gracefully
- 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
- Ability to use in various integration patterns
- Storage Options
- Tier-storage
- Others . . .
- Preservation-worthiness
...