1. 26 May, 2011 1 commit
  2. 18 May, 2011 1 commit
  3. 17 May, 2011 4 commits
    • Giorgos Verigakis's avatar
    • Giorgos Verigakis's avatar
      Add a simple client for the API · 1d54f4cf
      Giorgos Verigakis authored
      1d54f4cf
    • Sofia Papagiannaki's avatar
      Add unit tests for backend and API · b031b9f8
      Sofia Papagiannaki authored
      * Tests the OpenStack Object Storage API v1 functionality plus the extras
      * Tests the functionality of a BaseBackend which implements the API
      
      Fixes #451
      Fixes #453
      b031b9f8
    • Antony Chazapis's avatar
      Implement basic functionality plus some extras · 3c093bdb
      Antony Chazapis authored
      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
      3c093bdb
  4. 06 May, 2011 1 commit
  5. 05 May, 2011 8 commits
  6. 04 May, 2011 1 commit
  7. 03 May, 2011 4 commits
  8. 02 May, 2011 4 commits
  9. 29 Apr, 2011 1 commit
  10. 28 Apr, 2011 9 commits
  11. 27 Apr, 2011 2 commits
  12. 26 Apr, 2011 1 commit
  13. 25 Apr, 2011 1 commit
  14. 20 Apr, 2011 2 commits