Revision f5ed44df docs/source/devguide.rst

b/docs/source/devguide.rst
25 25
=========================  ================================
26 26
Revision                   Description
27 27
=========================  ================================
28
0.6 (Sept 05, 2011)        Reply with Merkle hash as the ETag when updating objects.
28
0.6 (Sept 08, 2011)        Reply with Merkle hash as the ETag when updating objects.
29 29
\                          Include version id in object replace/change replies.
30 30
\                          Change conflict (409) replies format to text.
31
\                          Tags should be migrated to a meta value.
31 32
0.5 (July 22, 2011)        Object update from another object's data.
32 33
\                          Support object truncate.
33 34
\                          Create object using a standard HTML form.
......
331 332
X-Container-Block-Size       The block size used by the storage backend
332 333
X-Container-Block-Hash       The hash algorithm used for block identifiers in object hashmaps
333 334
X-Container-Until-Timestamp  The last container modification date until the timestamp provided
334
X-Container-Object-Meta      A list with all meta keys used by objects
335
X-Container-Object-Meta      A list with all meta keys used by objects (**TBD**)
335 336
X-Container-Policy-*         Container behavior and limits
336 337
X-Container-Meta-*           Optional user defined metadata
337 338
Last-Modified                The last container modification date (regardless of ``until``)
338 339
===========================  ===============================
339 340

  
340
The keys returned in ``X-Container-Object-Meta`` are all the unique strings after the ``X-Object-Meta-`` prefix, formatted as a comma-separated list. See container ``PUT`` for a reference of policy directives.
341
The keys returned in ``X-Container-Object-Meta`` are all the unique strings after the ``X-Object-Meta-`` prefix, formatted as a comma-separated list. See container ``PUT`` for a reference of policy directives. (**TBD**)
341 342

  
342 343
================  ===============================
343 344
Return Code       Description
......
930 931

  
931 932
* Support for ``X-Account-Meta-*`` style headers at the account level. Use ``POST`` to update.
932 933
* Support for ``X-Container-Meta-*`` style headers at the container level. Can be set when creating via ``PUT``. Use ``POST`` to update.
933
* Header ``X-Container-Object-Meta`` at the container level and parameter ``meta`` in container listings.
934
* Header ``X-Container-Object-Meta`` at the container level and parameter ``meta`` in container listings. (**TBD**)
934 935
* Container policies to manage behavior and limits.
935 936
* Headers ``X-Container-Block-*`` at the container level, exposing the underlying storage characteristics.
936 937
* All metadata replies, at all levels, include latest modification information.
......
981 982
* The ``trash`` element, which contains files that have been marked for deletion, but can still be recovered.
982 983
* The ``shared`` element, which contains all objects shared by the user to other users of the system.
983 984
* The ``others`` element, which contains all objects that other users share with the user.
984
* The ``tags`` element, which lists the names of tags the user has defined. This can be an entry point to list all files that have been assigned a specific tag or manage tags in general (remove a tag completely, rename a tag etc.).
985 985
* The ``groups`` element, which contains the names of groups the user has defined. Each group consists of a user list. Group creation, deletion, and manipulation is carried out by actions originating here.
986 986
* The ``history`` element, which allows browsing past instances of ``home`` and - optionally - ``trash``.
987 987

  
988 988
Objects in Pithos can be:
989 989

  
990
* Assigned custom tags.
991 990
* Moved to trash and then deleted.
992 991
* Shared with specific permissions.
993 992
* Made public (shared with non-Pithos users).
......
995 994

  
996 995
Some of these functions are performed by the client software and some by the Pithos server.
997 996

  
997
In the first version of Pithos, objects could also be assigned custom tags. This is no longer supported. Existing deployments can migrate tags into a specific metadata value, i.e. ``X-Object-Meta-Tags``.
998

  
998 999
Implementation Guidelines
999 1000
^^^^^^^^^^^^^^^^^^^^^^^^^
1000 1001

  
......
1006 1007

  
1007 1008
Public objects are not included in ``shared`` and ``others`` listings. It is suggested that they are marked in a visually distinctive way in ``pithos`` listings (for example using an icon overlay).
1008 1009

  
1009
At the object level, tags are implemented by managing metadata keys. The client software should allow the user to use any string as a tag and set the corresponding ``X-Object-Meta-<tag>`` key at the server. The API extensions provided, allow for listing all tags in a container and filtering object listings based on one or more tags. The tag list is sufficient for implementing the ``tags`` element, either as a special, virtual folder (as done in the first version of Pithos), or as an application menu.
1010

  
1011 1010
A special application menu, or a section in application preferences, should be devoted to managing groups (the ``groups`` element). All group-related actions are implemented at the account level.
1012 1011

  
1013
Browsing past versions of objects should be available both at the object and the container level. At the object level, a list of past versions can be included in the screen showing details or more information on the object (metadata, tags, permissions, etc.). At the container level, it is suggested that clients use a ``history`` element, which presents to the user a read-only, time-variable view of ``pithos`` contents. This can be accomplished via the ``until`` parameter in listings. Optionally, ``history`` may include ``trash``.
1012
Browsing past versions of objects should be available both at the object and the container level. At the object level, a list of past versions can be included in the screen showing details or more information on the object (metadata, permissions, etc.). At the container level, it is suggested that clients use a ``history`` element, which presents to the user a read-only, time-variable view of ``pithos`` contents. This can be accomplished via the ``until`` parameter in listings. Optionally, ``history`` may include ``trash``.
1014 1013

  
1015 1014
Recommended Practices and Examples
1016 1015
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......
1063 1062

  
1064 1063
* List metadata keys used by objects in a container
1065 1064

  
1066
  Will be in the ``X-Container-Object-Meta`` reply header, included in container information or object list (``HEAD`` or ``GET``).
1065
  Will be in the ``X-Container-Object-Meta`` reply header, included in container information or object list (``HEAD`` or ``GET``). (**TBD**)
1067 1066

  
1068 1067
* List objects in a container having a specific meta defined ::
1069 1068

  

Also available in: Unified diff