[tahoe-lafs-trac-stream] [tahoe-lafs] #1526: make sure the new MDMF extension field is forward-compatible and safe

[tahoe-lafs]

#1526: make sure the new MDMF extension field is forward-compatible and safe
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  warner
         Type:  defect   |     Status:  closed
     Priority:           |  Milestone:  1.9.0
  critical               |    Version:  1.9.0a1
    Component:  code-    |   Keywords:  forward-compatibility mdmf design-
  mutable                |  review-needed review-needed
   Resolution:  fixed    |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 I reviewed [20111001233553-66853-bd5cc1fe18e7185f49d4c6205d2156fc4f44d194]
 and it looks good to me (except see below). It has a net reduction of
 source code, which is always good.

 One thing I noticed was that with this patch, if you have a cap with an
 extension field, and you parse it using
 [source:trunk/src/allmydata/uri.py?annotate=blame&rev=5305 uri.py] and
 then produce a cap from the resulting Python object, the cap produced will
 not have the extension on it. Could this be a problem if, in the future,
 someone sends a cap with an extension, and a user of Tahoe-LAFS v1.9
 inputs that cap into their Tahoe-LAFS implementation? Regardless of
 whether their Tahoe-LAFS v1.9 will ''show'' the extension field in copies
 of the cap that it produces/exports/displays, it will certainly not
 ''use'' the extension field for anything, so the only question is whether
 it is okay for the Tahoe-LAFS v1.9 implementation to omit the extension,
 which it is ignoring, from productions/exports/displays of that cap.

 Kevan: I would appreciate it if you would review this issue, and this
 patch, even though (or especially because) you earlier said you preferred
 the original behavior of parsing the extension field as a two-tuple of
 integers.

 David-Sarah: I would appreciate it if you would review this because you
 did such a great job of reasoning about forward-compatibility in previous
 iterations.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1526#comment:14>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage