Synnefo » Pithos

However, to be able to take full advantage of the Pithos infrastructure, client software should be aware of the extensions that differentiate Pithos from OOS. Pithos objects can be updated, or appended to. They can also be versioned, meaning that the server will track changes, assign version numbers and allow reading previous instances.

The storage backend of Pithos is block oriented, which allows for efficient, deduplicated data placement. The block structure of objects is exposed at the API layer, in order to encourage external software to implement advanced data management operations.

0.2 (May 29, 2011)         Add object meta listing and filtering in containers.

\                          Support for partial object updates through POST.

\                          Expose object hashmaps through GET.

The allowable request operations and respective return codes per level are presented in the remainder of this chapter. Common to all requests are the following return codes.

hash                 The ETag of the object

ETag                        The ETag of the object

|

======================  ===================================

Request Parameter Name  Value

======================  ===================================

format                  Optional extended reply type (can be ``json`` or ``xml``)

======================  ===================================

The reply is the object's data (or part of it), except if a hashmap is requested with the ``format`` parameter. Object headers (as in a ``HEAD`` request) are always included.

Hashmaps expose the underlying storage format of the object:

* Blocksize of 4MB.

* Blocks stored indexed by SHA256 hash.

* Hash is computed after trimming trailing null bytes.

Example ``format=json`` reply:

::

  {"hashes": ["7295c41da03d7f916440b98e32c4a2a39351546c", ...], "bytes": 24223726}

Example ``format=xml`` reply:

::

  <?xml version="1.0" encoding="UTF-8"?>

  <object name="file" bytes="24223726">

    <hash>7295c41da03d7f916440b98e32c4a2a39351546c</hash>

    <hash>...</hash>

  </object>

ETag                        The ETag of the object

Content-Length        The size of the data written (optional, to update)

Content-Type          The MIME content type of the object (optional, to update)

Content-Range         The range of data supplied (optional, to update)

Transfer-Encoding     Set to ``chunked`` to specify incremental uploading (if used, ``Content-Length`` is ignored)

The ``Content-Encoding``, ``Content-Disposition``, ``X-Object-Manifest`` and ``X-Object-Meta-*`` headers are considered to be user defined metadata. The update operation will overwrite all previous values and remove any keys not supplied.

To update an object:

* Supply ``Content-Length`` (except if using chunked transfers), ``Content-Type`` and ``Content-Range`` headers.

* Set ``Content-Type`` to ``application/octet-stream``.

* Set ``Content-Range`` as specified in RFC2616, with the following differences:

  * Client software MAY omit ``last-byte-pos`` of if the length of the range being transferred is unknown or difficult to determine.

  * Client software SHOULD not specify the ``instance-length`` (use a ``*``), unless there is a reason for performing a size check at the server.

* If ``Content-Range`` used has a ``byte-range-resp-spec = *``, data supplied will be appended to the object.

A data update will trigger an ETag change. The new ETag will not correspond to the object's MD5 sum (**TBD**) and will be included in reply headers.

No reply content. No reply headers if only metadata is updated.

==========================  ===============================

Reply Header Name           Value

==========================  ===============================

ETag                        The new ETag of the object (data updated)

==========================  ===============================

|

202 (Accepted)               The request has been accepted (not a data update)

204 (No Content)             The request succeeded (data updated)

416 (Range Not Satisfiable)  The supplied range is out of limits or invalid size

* Object hashmap retrieval through GET and the ``format`` parameter.

* Partial object updates through POST, using the ``Content-Length``, ``Content-Type``, ``Content-Range`` and ``Transfer-Encoding`` headers.