Winchester, MA The Fedora team has completed the seventh sprint within the "Beta Phase" of Fedora4 development that began with a a week-long hackfest  in Austin held alongside of the DLF conference. The majority of Sprint B7 developrs attended the hackfest in addition to some other Fedora developers. Two highlights of the event were:
• Consensus on targeted subset of 4.0 capabilities  scheduled for the next community-facing release
• Decision to host a Fedora 4 install-fest  where interested community members were invited to chat with the Fedora developers and install the software
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 email@example.com, or the Fedora Steering Committee firstname.lastname@example.org. 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 B7 summary:
About Sprint 7, Beta Phase
Benjamin Armintor - Columbia University
Frank Asseg - FIZ Karlsruhe
Nigel Banks - Discovery Garden
Chris Beer - Stanford University
Esme Cowles - University of California, San Diego (scrum master)
Osman Din - Yale University
Michael Durbin - University of Virginia
Eric James - Yale University
Continuing with the theme of authorization, this sprint put some finishing touches on the access roles module  which allows repository adminstrators to associate "read", "write", and "admin" roles with user principals on repository object and datastream nodes. The Fedora 4 authorization feature now ensures that:
• Child nodes of a requested node are not visible in API responses
• Deletion of a node will recursively delete its children nodes, unless the requesting user does not have sufficient privileges to delete one or more of the children, in which case the entire deletion operation will fail.
More details on the design and implementation of the authorization feature can be found on the following wiki page  and its sub-pages.
2) Simplified Deployment
One of the goals of Fedora 4 is to simplify the application deployment as well as the wiring of optional components and their subsequent configuration. Although there is a significant amount of work remaining towards this goal, one early step in this direction is the ability to deploy Fedora 4 by just dropping the web-application archive (war file) into a servlet container without the need for any additional configuration. Leveraging this simple deployment capability, this sprint produced a "one-click-run" download  which literally enables the user to click on the download to start up a local Fedora 4 repository.
A brief introduction to navigating the Fedora 4 web interface is documented on the wiki .
3) Large Files
This sprint furthered the support Fedora 4 offers for the management of large files. As mentioned in previous sprints, Fedora 4's initial approach with respect to large files is to expose the underlying ModeShape "projection" or "federation"  feature. In response to the performance issues revealed earlier, this sprint once again contributed updates to the ModeShape codebase that provide the option to either postpone the most time-intensive "federation" action (i.e. unique internal identifier generation based on content checksum) until the content is requested or to use a faster, surrogate internal identifier in the case where performance would otherwise be unacceptable.
Additional details of the "large files" approach can be found on the wiki .
4) Content Modelling
One aspect of Fedora 4 content modelling is the ability to define custom repository node-types including the node's composition (i.e. property types and multiplicity). In addition to the existing "compact node definition"  (CND) file, this sprint added the ability to define node-types at runtime via the Fedora 4 REST-API . This now allows repository managers to configure repository node-types programatically after the application has been installed.
This sprint introduced the first implementation of the versioning capability within Fedora 4. This initial implementation creates versions of individual object and datastream resources on all mutation events. Although not yet at the point of addressing the scope of versioning requirements, enough of the feature is in place to evaluate performance, storage, and general functionality which will inform subsequent iterations.
6) Feature Planning
The focus of this sprint was on progressing towards the specific subset of 4.0 capabilities ; however, some planning of future features also took place. Specifically, where there exists a risk that present design decisions should be informed by or take into consideration future capabilities, those capabilities are investigated to mitigate potential long-term impacts. Two such examples from this sprint are:
• Asynchronous REST-API 
• Runtime wiring and configuration  frameworks
As in most sprints, on-going improvements were made to the codebase and surrounding documentation.
• Integration tests were updated, including better coverage of HTML views
• HTML UI was updated
• RESTful status codes were reviewed
• Javadocs were supplemented
 https://wiki.duraspace.org/display/FF/Access+Roles+Module https://wiki.duraspace.org/display/FF/Design+-+Authentication+and+Authorization