Feature #447: Implement a "dummy" local backend - Synnefo - Greek Research and Technology Network's projects

The API is based on the Apr. 15, 2011 release of the OpenStack Object Storage API v1.
The implementation is broken up into two layers - frontend (API) and backend (data and metadata handling).
The API is documented in the wiki. The following list is copied here for reference.

List of differences from the OOS API and clarifications:

Authentication is done by another system. The token is used in the same way, but it is obtained differently. The top level GET request is kept compatible with the OOS API and allows for guest/testing operations.
Support for X-Account-Meta-* style headers at the account level. Use POST to update.
Support for X-Container-Meta-* style headers at the account level. Can be set when creating via PUT. Use POST to update.
Some processing is done in the variable part of all X-*-Meta-* headers. If it includes underscores, they will be converted to dashes and the first letter of all intra-dash strings will be capitalized.
All metadata replies, at all levels, include latest modification information.
At all levels, a GET request may use If-Modified-Since and If-Unmodified-Since headers.
A GET reply for a level will include all headers of the corresponding HEAD request.
To avoid conflicts between objects and virtual directory markers in container listings, it is recommended that object names do not end with the delimiter used.
The Accept header may be used in requests instead of the format parameter to specify the desired reply format. The parameter overrides the header.
Container/object lists use a 200 return code if the reply is of type json/xml. The reply will include an empty json/xml.
Container/object lists include all associated metadata if the reply is of type json/xml. Some names are kept to their OOS API equivalents for compatibility.
In headers, dates are formatted according to RFC 1123. In extended information listings, dates are formatted according to ISO 8601.
Object headers allowed, in addition to X-Object-Meta-*: Content-Encoding
Object MOVE support.

Fixes #445
Fixes #447

Revision b956618e
Added by Antony Chazapis almost 13 years ago

Implement basic functionality plus some extras

List of differences from the OOS API and clarifications:

Authentication is done by another system. The token is used in the same way, but it is obtained differently. The top level GET request is kept compatible with the OOS API and allows for guest/testing operations.
Support for X-Account-Meta-* style headers at the account level. Use POST to update.
Support for X-Container-Meta-* style headers at the account level. Can be set when creating via PUT. Use POST to update.
Some processing is done in the variable part of all X-*-Meta-* headers. If it includes underscores, they will be converted to dashes and the first letter of all intra-dash strings will be capitalized.
All metadata replies, at all levels, include latest modification information.
At all levels, a GET request may use If-Modified-Since and If-Unmodified-Since headers.
A GET reply for a level will include all headers of the corresponding HEAD request.
To avoid conflicts between objects and virtual directory markers in container listings, it is recommended that object names do not end with the delimiter used.
The Accept header may be used in requests instead of the format parameter to specify the desired reply format. The parameter overrides the header.
Container/object lists use a 200 return code if the reply is of type json/xml. The reply will include an empty json/xml.
Container/object lists include all associated metadata if the reply is of type json/xml. Some names are kept to their OOS API equivalents for compatibility.
In headers, dates are formatted according to RFC 1123. In extended information listings, dates are formatted according to ISO 8601.
Object headers allowed, in addition to X-Object-Meta-*: Content-Encoding
Object MOVE support.