[tahoe-lafs-trac-stream] [tahoe-lafs] #1513: memory usage in MDMF publish

[tahoe-lafs]

#1513: memory usage in MDMF publish
------------------------------+--------------------------
     Reporter:  warner        |      Owner:
         Type:  defect        |     Status:  new
     Priority:  minor         |  Milestone:  1.9.0
    Component:  code-mutable  |    Version:  1.9.0a1
   Resolution:                |   Keywords:  mutable mdmf
Launchpad Bug:                |
------------------------------+--------------------------

Comment (by davidsarah):

 Replying to [comment:1 warner]:
 >  * create an API to build a new version of the share one change at a
 time, then a second API call to finalize the change (and make the new
 version visible to the world). It might look something like the immutable
 share-building API.:
 >    * edithandle = share.start_editing()
 >    * edithandle.apply_delta(offset, newdata)
 >    * edithandle.finish()
 >    * edithandle.abort()
 >    * finish() is the test-and-set operation: it might fail if some other
 writer has completed their own start_editing()/apply_delta()/finish()
 sequence faster.

 I prefer this option: it allows the client to apply the deltas to all
 servers and confirm that those operations succeed, and only then send
 {{{finish}}} to all servers. But note that there needs to be an
 {{{edithandle.truncate(new_size)}}} operation, or alternatively
 {{{.finish(new_size)}}}.

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