[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):

 == Not uploading if the content exists ==

 The upload should of course be done in a way that benefits from the
 hashsum id. The client should be clever and check if it needs to upload by
 calculating the hashsum and doing a GET headers first on that blob.

 When an insufficiently clever client (eg a non-js browser) does upload a
 dup, the server figures that out and re-uses the existing object,
 discarding the new one, but using whatever filename the client wants to
 make a new link if needed.

 So ... the other thing needed is a way for the client to make a new link,
 without providing the actual content. Looks to me like in HTTP this has to
 be done via a GET perhaps to a specific query URI, or since it's a cheap
 operation, perhaps just make new names any time a user tries to GET
 something if they provide a hashsum and a filename?

 As alluded to earlier, filename doesn't really actually have to exist on
 the server at all for the cache files, the value could be filled from the
 request header. But storing these on-disk on the server allows searching
 (until users clutter it up too much with rubbish names, so how useful this
 is depends on the user context).

 Certainly the user wants to create links in their homedir. One solution is
 that the client is what handles those, rather than them being symlinks or
 whatever that the server can read. The client could use some kind of
 syntax like in the metadata files proposed earlier, to say, this object
 should be resolved by looking up this hashsum id. Then the user is just
 creating or overwriting a small plaintext metadata using a POST.

 The same mechanism could be used for in-cache objects filenames, but I
 think the extra network requests to resolve links at the client end makes
 it an unattractive choice.

 OK, now I think that's everything! ;-) ciao

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