Hello Fedora Community,
We have concluded the fifth sprint within the "Beta Phase" of Fedora4 development. The work of this and each sprint comes completely from the contribution of Fedora stakeholder institutions in allocating developer time. If you would like to become involved with Fedora4 development, please send me an email. If you have comments on the work from this sprint, please send an email or comment directly on the wiki.
Below is a link to the Sprint B5 summary (also included in-full in this email's body):
Michael Durbin - University of Virginia
Ye Cao - Max Planck Digital Library
Osman Din - Yale University
Nigel Banks - Discovery Garden
Adam Soroka - University of Virginia
Frank Asseg - FIZ Karlsruhe
1) Fedora 3 to 4 Upgrade
This sprint had a focus on refining the Fedora 3 to 4 Upgrade feature.
The previous implementation enabled connecting to a Fedora 3 repository, and exposing its objects in a flat, single-level structure within the Fedora 4 repository. In an effort to improve the performance of the connector used to project over a Fedora 3 repository, these objects are now internally structured as a multi-level tree with a configurable number of children nodes at each branch-point in the tree. The result is that accessing any given node now leverages tree searching logic, and load-time is reduced to only what is required in loading the objects at a given point in the tree.
More description of the Fedora 3 to 4 Upgrade capability can be found on the wiki .
2) Islandora Integration
Although the Islandora/Fedora 4 integration does not generally involve updates within the Fedora codebase, this work is included in sprints due to the importance of ensuring Islandora expectations and Fedora development remain synchronized.
This sprint initiated the effort of retooling the Islandora/Fedora connector (Tuque) to dynamically construct the appropriate Fedora client based on the discovered version of the backend Fedora repository. This sprint represents a significant step towards enabling Islandora's support for either a Fedora 3 or Fedora 4 backend.
One of the limitations of Fedora 3 has been the inability to scale the repository horizontally in support of increased access requests, high-availability, and/or bulk ingesting.
Fundamentally, Fedora 4 inherits clustering capabilities from the underlying ModeShape platform.
This sprint started the process of provisioning two independent clusters from stakeholder institutions and establishing performance benchmarks over those clusters. The configuration and tuning of Fedora 4 clusters will be a common sprint theme until appropriate performance numbers have been achieved.
One of the hallmarks of an agile development process is the inherent commitment to continual refinement and refactoring of the codebase.
In the course of implementing and testing the Fedora 3 to 4 Upgrade capability, performance limitations were discovered when loading hundreds of thousands of objects. The ground-work for addressing these issues was laid during this sprint. Namely, the underlying model of iterating over objects and properties was introduced in replacement of the approach of loading these all into memory.
Subsequent sprints will expose this iteration model at the Fedora user API level.