Keep manifest format » History » Version 6

Tom Clegg, 06/13/2015 05:06 AM

1 3 Tom Clegg
{{toc}}
2 3 Tom Clegg
3 1 Tom Clegg
h1. Keep manifest format
4 1 Tom Clegg
5 1 Tom Clegg
h2. Manifest v1
6 1 Tom Clegg
7 6 Tom Clegg
A manifest is utf-8 encoded text, consisting of zero or more newline-terminated streams.
8 1 Tom Clegg
9 1 Tom Clegg
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 5 Tom Clegg
** The first path component is always @"."@.
12 5 Tom Clegg
** No path component is empty.
13 5 Tom Clegg
** No path component is "." or "..".
14 5 Tom Clegg
** 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 1 Tom Clegg
** If a subsequent token ("hint") in the locator is numeric, it indicates the size of the data blob, in bytes.
17 1 Tom Clegg
** 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 1 Tom Clegg
* ...possibly followed by more data blob locators...
19 1 Tom Clegg
* The first token that is not a block locator, and all subsequent tokens, are file tokens.
20 1 Tom Clegg
** A file token has three parts, delimited by @":"@: position, size, filename.
21 1 Tom Clegg
** Position and size are given in decimal, and are counted from the beginning of the first data blob.
22 1 Tom Clegg
** 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 5 Tom Clegg
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 6 Tom Clegg
A manifest always ends with a newline -- except the empty (zero-length) string, which is a valid manifest.
28 1 Tom Clegg
29 1 Tom Clegg
h2. Normalized manifest v1
30 1 Tom Clegg
31 1 Tom Clegg
A normalized manifest has the following additional restrictions.
32 1 Tom Clegg
* Streams are in alphanumeric order.
33 1 Tom Clegg
* Each stream name is unique within the manifest.
34 1 Tom Clegg
* Files within a stream are in alphanumeric order.
35 1 Tom Clegg
* -Concatenation @stream_name/filename@ is unique within the manifest.- (This can be impossible to accomplish without rewriting blobs.)
36 1 Tom Clegg
* Filename must not contain @"/"@.
37 1 Tom Clegg
38 1 Tom Clegg
An API call -exists- will exist to normalize a manifest.
39 1 Tom Clegg
40 1 Tom Clegg
Request:
41 1 Tom Clegg
* @POST /arvados/v1/collections/{hash}/normalize@
42 1 Tom Clegg
* request body: @{"collection":{"manifest_text":"...."}}@
43 1 Tom Clegg
44 1 Tom Clegg
Response:
45 1 Tom Clegg
* @{"uuid":"...","manifest_text":"..."}@
46 1 Tom Clegg
47 1 Tom Clegg
Notes:
48 1 Tom Clegg
* POST despite no side effects.
49 1 Tom Clegg
* Returns object with uuid even though no object was stored.
50 3 Tom Clegg
51 3 Tom Clegg
h2. Manifest v2
52 3 Tom Clegg
53 3 Tom Clegg
(Early design stages)
54 3 Tom Clegg
55 3 Tom Clegg
Should probably include:
56 3 Tom Clegg
* Structured format (JSON?)
57 3 Tom Clegg
* More than one level of indirection (e.g., manifest references block X, which references data blocks A,B,C)
58 3 Tom Clegg
* Specify hash algorithm with block hashes