[tahoe-lafs-trac-stream] [tahoe-lafs] #510: use plain HTTP for storage server protocol

[tahoe-lafs]

#510: use plain HTTP for storage server protocol
------------------------------+---------------------------------
     Reporter:  warner        |      Owner:  zooko
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.2.0
   Resolution:                |   Keywords:  standards gsoc http
Launchpad Bug:                |
------------------------------+---------------------------------

Comment (by simeon):

 Replying to [comment:27 simeon]:
 > Replying to [comment:26 zooko]:
 > >
 > > > Various behaviours relating to Content-Range are forbidden by the
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html HTTP 1.1 spec],
 but which one were you referring to?
 > >
 > > Described here: https://github.com/warner/tahoe-
 lafs/commit/3f6e2f196dc654b8f846b2bc0d174382bf6d59c5#commitcomment-4376374
 >
 > AFAIK it is permitted to combine pipelining
 (https://en.wikipedia.org/wiki/HTTP_pipelining) and keep-alive
 (https://en.wikipedia.org/wiki/HTTP_persistent_connection) along with
 content-range, the overhead would not be very great, and perhaps some HTTP
 header fields could be omitted in such a communication.
 >
 > I wonder if it's better perhaps to store large files as a series of
 fixed-maximum-size chunks, and have the client do the logic to reassemble
 them ... ? (Haven't read much about your implementation, and actually in
 my own similar work, i originally concluded to opt for simplest usage at
 client end ... so really that comment is not backed by anything, just
 musing...)

 For an effective method of splitting large files in a way that preserves
 de-duplicatability, see debian's addition to gzip
 (http://svana.org/kleptog/rgzip.html) which creates gzip files that can be
 reliably and effectively de-duplicated even when some of the data has
 changed, which helps rsync stay useful. AFAIK they are still using the
 same 'stupid' algorithm, and it has been incorporated into the standard
 system tools so that debs are indeed rsyncable through various versions of
 deb.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510#comment:28>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage