[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:
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  1.9.0
  critical               |    Version:  1.9.0a1
    Component:  code-    |   Keywords:  forward-compatibility mdmf design-
  mutable                |  review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by kevan):

 I like the conservatism of precisely specified and restrictive extension
 fields; it makes me more comfortable with the idea of extension fields,
 since it's easier for me to reason about the form of a valid cap and feel
 confident that we haven't inadvertently allowed caps that we don't want to
 allow.  It is kind of silly to add a restriction like that before we even
 start writing the code that might one day use the extensions, though, and
 my objection isn't anything more than a vague unease with the idea.

 I think that the code at the moment simply populates the k and segsize
 values -- it doesn't try to use them. Actually, aside from the restrictive
 nature of the extension fields at the moment, proposal 1 is what the
 current code does.

 As I understand it, the extension fields are meant to advisory. That is,
 any part of Tahoe-LAFS that uses them to work with a file should tolerate
 cases in which they're wrong. So we'd treat the remote share's
 representation of the segsize, k, or whatever else we choose to stick in
 the cap as canonical, and defer to it in the event of an inconsistency.

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