From dacdf57b2a7009dd8832d5093c13735212995244 Mon Sep 17 00:00:00 2001 From: Brett Slatkin Date: Fri, 21 Jan 2011 10:53:22 -0800 Subject: [PATCH] various tiny fixes to docs --- doc/json-signing/json-signing.txt | 6 ++++-- doc/overview.txt | 20 ++++++++++---------- 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/doc/json-signing/json-signing.txt b/doc/json-signing/json-signing.txt index b46452706..d5c688b41 100644 --- a/doc/json-signing/json-signing.txt +++ b/doc/json-signing/json-signing.txt @@ -35,7 +35,7 @@ worth the cost. Overall, though, the jchris approach's structure of the JSON file is good. -Notably, it satisifies on of my other goals: +Notably, it satisfies on of my other goals: GOAL #2) The document still be human-readable. @@ -102,6 +102,8 @@ SIGNING -- the resulting string is 'C', the camli-signed JSON document. + (The output file is in doc/example/signing-after.camli) + In review: O == the object to be signed @@ -141,6 +143,6 @@ VERIFYING -- using 'camliSigner', a camli blobref, find the blob (cached, via camli/web lookup, etc) that represents a GPG public key. --- use GnuPG or equivalent libraries to verify that the ASCI-armored +-- use GnuPG or equivalent libraries to verify that the ASCII-armored GPG signature in "camliSig" signs the bytes in 'BP' using the GPG public key found via the 'camliSigner' blobref diff --git a/doc/overview.txt b/doc/overview.txt index 6852e9cee..821dc3599 100644 --- a/doc/overview.txt +++ b/doc/overview.txt @@ -49,7 +49,7 @@ Schema of files/objects in Layer 1: * Let's start by describing the storage of files that aren't self-describing, e.g. "some-notes.txt" (as opposed to a jpg file from a camera that might likely contain EXIF data, addressed later...). This file, for reference, - is in doc/example/some-notes.txt + is in doc/json-signing/example/some-notes.txt * The bytes of file "some-notes.txt" are stored as-is in one blob, addressed as "sha1-8ba9e53cbc83c1be3835b94a3690c3b03de0b522". @@ -68,20 +68,20 @@ Schema of files/objects in Layer 1: in-line. This file would thus be represented by a JSON file, as seen in - docs/examples/some-notes.txt.camli, and addressed as - "sha1-7e7960756b39cd7da614e7edbcf1fa7d696eb660", its sha1sum. - This identifier can be used in directory listings, etc. - Note that camli files do not have any magical filename, as they're - not typically stored with their filename. (they are in the doc/examples/ - directory just to separate them out, but that's a rare case.) - Instead, a camli JSON object is known as such if the bytes of the file - begin exactly with the bytes: + docs/json-signing/example/some-notes.txt.camli, and addressed as + "sha1-7e7960756b39cd7da614e7edbcf1fa7d696eb660", its sha1sum. This identifier + can be used in directory listings, etc. Note that camli files do not have any + magical filename, as they're not typically stored with their filename. (they + are in the doc/json-signing/examples/ directory just to separate them out, but + that's a rare case.) Instead, a camli JSON object is known as such if the + bytes of the file begin exactly with the bytes: {"camliVersion" ... which lets upper layers know what it is, and how to index it. - See spec.txt for details on Camli JSON objects and their schema. + See the doc/schema/ directory for details on Camli JSON objects and their + schema. * Note that camli files can represent: