- on the verge of wrapping up 6mo of dev sprints, from a good sized community.
- but it all started way back in, like, 2-3 years ago.
- goal is to get done by OR13
- Steering group
- self formed at OR12, performance issues.
- determined to get funding fom participating institutions, and that seemed to work / be working.
Longer Term Goals:
- not break peoples existing apps
- preserve some of the Fedora 3 way of doing things, esp. re: durability
- looking ahead 5-10 years.
- Scalability, through clustering nodes. Fedora 3 really can't do that.
- Multi-tenency, e.g. hosted Fedora vendors; institutions where central dept manages fedora repos for other depts.
- byte-stream data. Fedora 3 falls short with large files
- Graphs, Description and Navigating the repo though the api, with intuitive responses.
- Repository durability. FCR3 has perforamnce bottlneck when serializing Foxml.
- is part of the issue w/ latency of uploading large files
- OAuth support w/in Fedora
- thinner and lighter kernel.
- remove extraneous features
- results in more sustainable codebase
- testable goals w/ metrics
- First fedora 4 delivarble was a test harness to compare performance
- should be avail on github (cbeer, eddies, barmintor many know?)
Some metrics on progress:
- very large reductions in lines of code, ~20x smaller.
- unit test coverage went from ~10% to ~80%
Dev stack for Fedora 4
- ModeShape + JCR + Fedora
- Objects can contain objects.
- arbitrary paths, i.e. clean looking URL to the REST api.
Checksums and de-duplication
- data gets de-duplicated, i.e. it does a checksum on objects to see if it's already there, and if so, does not save it twice.
- Thus checksums are required.
- privileged datastreams RELS-EXT and DC are going away.
- no longer needed with RDF responses.
- returns not only requested object, but parent, and children as well.
- must register them in F4
- so far no solid strategies have been decided upon. But if UVA or Stanford (likely among the early adapters) make movement on this, community would be interested in seeing the migration plan.
- expect a migration path
- What's the current policy for backward compatability?
- no promises of 100% backward compatibility, however...
- the api was developed to look a lot like Fedora 3
- strongly advised against using SOAP, since the SOAP api may not look as much like the http api.
Implications for Active Fedora
- Rubydora has made a lot of headway, nearly working :)
- Should not have to change RELS-EXT implementations, i.e. relationships can be handled the same way.
Policy driven storage
- currently based on mime-type
- could conceivably be based on pid, or namespace
Supporting the development effort
- More help is needed
- now is a good opportunity to contribute cycles, particularly coinciding with OR13.
- Buzz among institutions: Duke, Yale, London School of Ec. , BPL.
* Questions about FCR4? Send to firstname.lastname@example.org.