This Confluence wiki site, maintained by DuraSpace prior to the recent merger with LYRASIS, will transition from the duraspace.org domain to the lyrasis.org domain on Saturday, Nov 16 beginning at approximately 7pm ET. A period of downtime of 2-3 hours is expected. After the transition, this wiki will be available at https://wiki.lyrasis.org/. All links to duraspace.org wiki pages will be redirected to the correct lyrasis.org URL. If you have questions prior to or following the transition please contact: wikihelp@lyrasis.org.
Skip to end of metadata
Go to start of metadata

Scope & Objectives

This group will work towards generating a Minimum Viable Product (MVP) repository solution which enables the use of multiple disparate storage backends for both files and metadata using the Data Mapper pattern, as a proof-of-concept for improving the flexibility of the Samvera architecture. In doing so, it will broaden the potential adoption base and provide the ability to compare pros/cons of various configurations for each institution. This group will attempt a solution which:

1) Enables persistence of metadata into at least two different backends (one being Fedora.)

2) Enables persistence of binary resources (files) into at least two different backends (one being Fedora.)

3) Reduces the dependence of Samvera's front-end on inter-community gems, preferring solutions with a larger adoption.

4) Provides a suite of tests for creating further backends without altering the front-end business logic.


Assuming success, the group will build a list of strategies for implementing this code in the core Samvera infrastructure.

Deliverables & Timeframe

  1. Generate an MVP repository which can persist to two or more backends.
    1. Agree upon a representative set of features necessary for confidence that this strategy will work in the core of Samvera.
    2. Participate in scheduled week-long development efforts for development.
    3. Recognize and document differences between persistence backends and the impact of use cases on our requirements for each.
  2. On Success
    1. Generate a document of recommendations on how to implement the code in the core of the Samvera stack.
    2. Found here: Hyrax Implementation Recommendations
  3. On Failure
    1. Generate documentation on what failed, why, and potential next steps.

The group can begin in early May 2017. The group will be sunset by November 2017, with a report during Samvera Connect.

Meeting Times & Communication Channels

Members

Note that to be a member of a Working Group, you must have have a CLA in place if you are committing code and you must consent to release documentation under a Creative Commons Attribution-Share Alike 3.0 Unported License.

Community Sprint Reports

Resources

Meeting Notes

  1. Running Notes: https://docs.google.com/document/d/1BeKVY5t5vrX7JNuDSMJz1MpEz09Poe0X1h02Y1gUFAg/edit


  • No labels