Hello Fedora Community,
We have concluded the first 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 or the Fedora Steering Committee (cc'd here) an email. If you have comments on the work from this sprint, please send an email or comment directly on the wiki. Finally, the addition of your descriptive use cases to the wiki [1] is valuable in informing on-going development.

Below is a link to the Sprint B1 summary (also included in-full in this email's body):

Andrew Woods

Development Team 

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

Sprint Themes

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 - 9/6).

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 - 8/23).
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 Edwards Island
- Yale University

[1] https://wiki.duraspace.org/display/FF/Use+Cases
[2] https://wiki.duraspace.org/display/FF/Design+-+Authentication+and+Authorization
[3] https://wiki.duraspace.org/display/FF/Design+-+Policy+Driven+Storage
[4] https://wiki.duraspace.org/display/FF/Islandora+and+Fedora+4
[5] https://wiki.duraspace.org/display/FF/Design+-+OAI-PMH