You are here

Block title
Block content

Fedora Futures Completes First Beta Phase "Sprint"

Winchester, MA
 The Fedora Futures team is pleased to announce the conclusion of the first "sprint"–a full speed software development run over a short period of time–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 Andrew Woods, or the Fedora Steering Committee an email. If you have comments on the work from this sprint, please also send an email or comment directly on the wiki. Contributing your institution's descriptive use case(s) to the wiki [1] is particularly valuable in informing ongoing Fedora development.

Read the Sprint B1 summary:

About Sprint 1, Beta Phase

Development Team 

Osman Din - Yale University
Greg Jansen - University of North Carolina, Chapel Hill
Yuqing Jiang - University of Prince Edward Island


1) Authentication and Authorization

Given the diversity of use cases and scenarios, this sprint focused on analyzing different strategies for authentication as well as for authorization in the Fedora4 context.  Authentication strategies which were considered include:

• Servlet container authentication
• Web server authentication, and
• OAuth 2.0 authentication

Authorization strategies which were considered include:

• Modeshape native authorization
• Servlet authorization
• External Policy Decision Point authorization

Special attention was given to the trade-offs between storing the authorization policies within the repository versus in an external component.

The design notes are available on the wiki [2].

Based on the analysis of this sprint and the feedback it generates, a limited implementation will begin during sprint B3 (8/26/13 - 9/6/13).

2) Policy-driven Storage

In the Fedora4 context, policy-driven storage refers to the ability to configure the repository to route content to different backend persistence stores based on attributes or characteristics of the content.

The Alpha-phase of development created an implementation that configured this routing in an XML file based on content mime-type.

In alignment with the top-level goal of simplifying repository configuration by offering run-time, web-based configuration, this sprint prototyped creating and updating policy-driven storage configuration via an HTTP endpoint and storing the configuration within the repository itself.

The prototype will be incorporated into the Fedora4 codebase during sprint B2 (8/12/13 - 8/23/13). 

More description of the policy-driven storage design can be found on the wiki [3]. 

3) Islandora Integration

One of the requirements of Fedora4 development is ensuring that interoperability of Islandora with Fedora4 is maintained.

In greater support for linked-data, the Fedora4 HTTP API responds with RDF.

This sprint included updates to Islandora's Fedora client library to translate the RDF responses into the model expected by Islandora. More description of the Islandora/Fedora4 integration can be found on the wiki [4]. 


Although OAI-PMH was not scheduled to be included in this sprint, interest and support from both the University of Texas, Austin and the University of New South Wales initiated the exploration of a Fedora4 OAI-PMH implementation.

More description of the OAI-PMH design can be found on the wiki [5]. 

If you would like to participate in the OAI-PMH initiative, please send an email or comment on the wiki. 

5) Developer Capacity

In addition to the features extended in this sprint, one of the significant outcomes was the expansion of the development capacity within the Fedora community. Two developers new to the Fedora4 project worked on this sprint from:

• University of Prince Edward Island
• Yale University