This page will be used to design an asynchronous storage feature.

Guiding Principles

1. Any Fedora4 feature should be available through an API which is an implementation of LDP or an optional extension (ideally an existing standard)
2. Fedora4 features should favor existing tools over custom code
3. Fedora4 features should establish integration patterns where an implementation is not a part of the core code

Use Cases

• Page:
  Scalability for Asynchronous Ingest, Access and Audit (Fedora Repository)

  • uc-storage-async
  • fedora6usecase
• Page:
  Leverage Cloud Storage (Fedora Repository)

  • uc-storage-async
  • fedora6usecase
• Page:
  Repository supports Amazon Glacier, or other asynchronous storage services (Fedora Repository)

  • uc-storage-async
• Page:
  Support for Hierarchical Storage Management-like systems (Fedora Repository)

  • uc-storage-async
• Page:
  Hybrid Use Case (Fedora Repository)

  • uc-storage-async
  • uc-storage-policy
  • uc-legacy

Actions

...

Proposed Requirements

1. The Fedora 4 REST-API MUST expose a mechanism for clients to request asynchronous content.
2. When the content is prepared, the Fedora 4 client MUST have a means of receiving a notification.
3. When the content is prepared, the Fedora 4 client MUST have some window of time (24h?) to retrieve it from the resulting URL before it expires
   1. The server MAY cache the content response (if appropriate) for some length of time.
   2. The server MAY expose the cached response at the original request endpoint.

Role Commitments

Development

...

Stakeholder

...