Fedora4 Beta Phase Sprint Ten: Federation; Clustering; Pluggable Framework
Submitted by on Tue, 2014-02-11 12:15
Winchester, MA The Fedora team has concluded the tenth sprint within the "Beta Phase" of Fedora4 development. The work of this and each sprint is planned and completed thanks to the contributions of Fedora stakeholder institutions which allocate developer time. If you would like to be involved with Fedora4 development, please send an email to Andrew Woods firstname.lastname@example.org, or to email@example.com. If you have comments on the work from this sprint, please also send an email or comment directly on the wiki.
Read the the Sprint B10 summary:
About Sprint 10, Beta Phase
Frank Asseg - FIZ Karlsruhe
Adam Soroka - University of Virginia
One of the Fedora 4 features that holds significant potential for addressing several use cases, including "large files", "managed external datastreams", and a variety of other scenarios where content already exists in a backend storage system, is Federation  (aka Projection). This sprint enhanced the "file system federation" connector to act on federated content in a manner more similar to how direct repository assets are managed. Specifically, the ability to add/update/delete properties on federated resources was added. Additionally, the ability to perform the repository's native fixity checks over federated content was implemented.
Clustering of Fedora 4 in support of horizontal application scalability, geographic distribution, high availability, etc. is one of the driving motivations for the architectural shift from Fedora 3. This sprint continued the effort of determining a clustering configuration that can demonstrate increased ingest performance over a single-server installation. Initial configurations towards this goal have been documented in the wiki . The capability will continue to receive development attention.
3) Pluggable Framework
Some features add value by lowering the bar to entry for new developers as well as by simplifying the process of integrating new functionality. Additionally, basic architectural foundations are almost always easier to establish earlier in an application's evolution than later. Investigations were made in this sprint towards an architecture that enables development of new features without requiring a developer to understand/build the entire codebase. Additionally, these investigations lead to the ability to deploy/undeploy functional modules at runtime.
As with previous and future sprints, on-going improvements were made to the codebase and supporting documentation.
• External triplestores now completely remove related triples on a "resource delete" event
• Kernel interfaces factored out of implementation classes
• Build artifact names updated for readability