Changes between Version 12 and Version 13 of Capabilities

Timestamp:

2011-08-07T15:37:32Z (13 years ago)

Author:

davidsarah

Comment:

formatting

Capabilities

@@ -22 +22 @@
 
 13: unknown/future capability strings                     <anything else>
+}}}
 
 In Tahoe-LAFS, mutable directories are built out of mutable files (a mutable directory is really
@@ -28 +29 @@
 uploaded into immutable files by default.
 
-Some capabilities can be used to derive others. If you have #1, you can
-derive #2 (but not the other way around). The full table is:
-
+Some capabilities can be used to derive others. If you have !#1, you can
+derive !#2 (but not the other way around). The full table is:
+{{{
   write   read  verify
   --------------------
@@ -40 +41 @@
            #9          }  dircaps
    #10 -> #11 -> #12   }
+}}}
 
 Deriving a weaker capability from a strong one is called "diminishing" the stronger one.
 
-So we use "filecap" to talk about #1..6, but (since most files are immutable)
-we're usually talking about #1. We use "dircap" to talk about #7..12.
-We use "readcap" to talk about #{1,3,5,7,9,11}, but usually we refer to
-#{7,9,11} as a "directory readcap". We use "writecap" to talk about #4 and #10.
+So we use "filecap" to talk about !#1..6, but (since most files are immutable)
+we're usually talking about !#1. We use "dircap" to talk about !#7..12.
+We use "readcap" to talk about !#{1,3,5,7,9,11}, but usually we refer to
+!#{7,9,11} as a "directory readcap". We use "writecap" to talk about !#4 and !#10.
 
-A "literal cap" or "LIT cap" stores the contents of a small file (#3) or
-directory (#9) in the capability itself.
+A "literal cap" or "LIT cap" stores the contents of a small file (!#3) or
+directory (!#9) in the capability itself.
 
 A "verifycap" is the weakest capability that still allows every bit of every
 share to be validated (hashes checked, signatures verified, etc). That means
-#{2,6,8,12}.
+!#{2,6,8,12}.
 
 When we talk about a "repaircap", we mean "the weakest capability that can
 still be used to repair the file". Given the current limitations of the
-repairer and our webapi, that means we're talking about #{1,4,7,10}.
-Eventually we'll fix this limitation, and any verifycap should be useable as
-a repaircap too. (There's much less work involved to let #2 repair a file or
-#8 repair a directory... it's just an incomplete API, rather than a fundamental
+repairer and our web-API, that means we're talking about !#{1,4,7,10}.
+Eventually we'll fix this limitation, and any verifycap should be usable as
+a repaircap too. (There's much less work involved to let !#2 repair a file or
+!#8 repair a directory... it's just an incomplete API, rather than a fundamental
 redesign of the server protocol.)
 
@@ -68 +70 @@
 filesystem. It might be remembered in the allmydata.com rootcap database
 (indexed by account name plus password), or it might be remembered in a
-~/.tahoe/private/aliases file, or it might just be written down on a piece
+{{{~/.tahoe/private/aliases}}} file, or it might just be written down on a piece
 of paper. The point is that you have to start from somewhere, and we refer
 to such a starting point as a "rootcap".
-
-}}}