[tahoe-dev] [tahoe-lafs] #280: get_hash method in webapi for extension caching logic.

[tahoe-lafs]

#280: get_hash method in webapi for extension caching logic.
---------------------------+------------------------------------------------
     Reporter:  nejucomo   |        Type:  enhancement             
       Status:  new        |    Priority:  minor                   
    Milestone:  undecided  |   Component:  code-frontend-web       
      Version:  0.7.0      |    Keywords:  webapi caching extension
Launchpad_bug:             |  
---------------------------+------------------------------------------------

Comment(by nejucomo):

 The comments above seem to only consider a well-known hash function, like
 SHA256, and indeed it seems like including such a hash would add some
 overhead or complexity to the storage format.  This might be worth it.

 However, when I originally wrote this, I imagined there was some hashtype
 which was "innate" to Tahoe storage structures, and therefore this call
 could extract that information efficiently from a Cap.

 After a quick skim of the architecture doc, it sounds like there is a
 merkle tree stored in the capability extension block.  If this is a tree
 over the plain text, then the root of this tree could be efficiently
 returned by the proposed call, such as:

 get_hash(myCap, "tahoe_content_merkle_tree_root")

 Clients would then need to compute a merkle tree, but I expect this would
 be somewhat simple and efficient, given the right library for computing
 merkle trees.

 Because I've noticed a thread on tahoe-dev about caching, and I've seen
 some tickets related to caching, I'm going to link all of these related
 tickets and threads together.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/280#comment:6>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid