Keep manifest format » History » Version 6
Tom Clegg, 06/13/2015 05:06 AM
| 1 | 3 | Tom Clegg | {{toc}} |
|---|---|---|---|
| 2 | |||
| 3 | 1 | Tom Clegg | h1. Keep manifest format |
| 4 | |||
| 5 | h2. Manifest v1 |
||
| 6 | |||
| 7 | 6 | Tom Clegg | A manifest is utf-8 encoded text, consisting of zero or more newline-terminated streams. |
| 8 | 1 | Tom Clegg | |
| 9 | Each stream consists of three or more space-delimited tokens: |
||
| 10 | 5 | Tom Clegg | * The first token is a stream name, consisting of one or more path components, delimited by @"/"@. |
| 11 | ** The first path component is always @"."@. |
||
| 12 | ** No path component is empty. |
||
| 13 | ** No path component is "." or "..". |
||
| 14 | ** The stream name never begins or ends with @"/"@. |
||
| 15 | 1 | Tom Clegg | * The second token is a data blob locator, consisting of one or more tokens, delimited by @"+"@, the first of which is an MD5 hexdigest. |
| 16 | ** If a subsequent token ("hint") in the locator is numeric, it indicates the size of the data blob, in bytes. |
||
| 17 | ** If a hint starts with @"A"@, it is an authorization token (used by the Keep server to confirm that the block is readable by a specific API auth token). |
||
| 18 | * ...possibly followed by more data blob locators... |
||
| 19 | * The first token that is not a block locator, and all subsequent tokens, are file tokens. |
||
| 20 | ** A file token has three parts, delimited by @":"@: position, size, filename. |
||
| 21 | ** Position and size are given in decimal, and are counted from the beginning of the first data blob. |
||
| 22 | ** Filename may contain @"/"@ characters, but must not start or end with @"/"@, and must not contain @"//"@. |
||
| 23 | 5 | Tom Clegg | ** Filename components (delimited by @"/"@) must not be @"."@ or @".."@. |
| 24 | |||
| 25 | 1 | Tom Clegg | A manifest contains no TAB characters, nor other ASCII whitespace characters other than the spaces or newline delimiters specified above. |
| 26 | 6 | Tom Clegg | |
| 27 | A manifest always ends with a newline -- except the empty (zero-length) string, which is a valid manifest. |
||
| 28 | 1 | Tom Clegg | |
| 29 | h2. Normalized manifest v1 |
||
| 30 | |||
| 31 | A normalized manifest has the following additional restrictions. |
||
| 32 | * Streams are in alphanumeric order. |
||
| 33 | * Each stream name is unique within the manifest. |
||
| 34 | * Files within a stream are in alphanumeric order. |
||
| 35 | * -Concatenation @stream_name/filename@ is unique within the manifest.- (This can be impossible to accomplish without rewriting blobs.) |
||
| 36 | * Filename must not contain @"/"@. |
||
| 37 | |||
| 38 | An API call -exists- will exist to normalize a manifest. |
||
| 39 | |||
| 40 | Request: |
||
| 41 | * @POST /arvados/v1/collections/{hash}/normalize@ |
||
| 42 | * request body: @{"collection":{"manifest_text":"...."}}@ |
||
| 43 | |||
| 44 | Response: |
||
| 45 | * @{"uuid":"...","manifest_text":"..."}@ |
||
| 46 | |||
| 47 | Notes: |
||
| 48 | * POST despite no side effects. |
||
| 49 | * Returns object with uuid even though no object was stored. |
||
| 50 | 3 | Tom Clegg | |
| 51 | h2. Manifest v2 |
||
| 52 | |||
| 53 | (Early design stages) |
||
| 54 | |||
| 55 | Should probably include: |
||
| 56 | * Structured format (JSON?) |
||
| 57 | * More than one level of indirection (e.g., manifest references block X, which references data blocks A,B,C) |
||
| 58 | * Specify hash algorithm with block hashes |