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

 "...everything else done at a client end, apart from exchanging objects
 between backend nodes and deprecation."

 Perhaps since deprecation is handled by the server, then locking/blocking
 should also be, which seems to be easy to use rw user perms for, which
 would mean having an API switch for a user to say mark file as -w or -r
 ... and this I think seems a nice way to solve that, because it means an
 actual UNIX user rather than an interface user, can do something quick to
 clean out a cache without losing things they have marked as 'keep'. But
 it's not a feature that I am married to. :) But I think the API switch
 would be useful, and this is one of the few factors that I think speak one
 way or the other about whether to store whole-files or arrays of chunks
 and so forth. The problem can still be solved in the array-of-chunks
 system, if the clients know to make such markings in a metadata file, and
 the server knows to look in metadata files before deprecating files ...

 I guess its a feature that would be too costly UNLESS it was implemented
 via the filesystem flags.

 For my usage case, I see the idea as one way of reducing the number of
 admin requests for file deletion. If the policy is 'you can delete it
 yourself' and 'you can lock it yourself', ie 'fight it out with other
 users (of your node)' that might be one way to run a low-admin node. Since
 the db is distributed, the meaning of 'deleted' 'not deleted' 'blocked'
 'not blocked' are softened anyway, but I think people click 'complain' for
 irrational reasons, less than rational ones. A 'delete' button might
 asuage this. And would be useful for the case where it's a private db. I
 see this as a configurable option in my system, you could set it up
 various ways via a config file, eg only allow certain users to use the
 flags, allow everyone, don't allow anyone, don't even respect the flags if
 they are set already, etc.

 Also allows a UNIX user/admin to override the behaviours without having to
 learn or expose themselves to the interface (which may be desirable for
 paranoia reasons eg virus, or technical ones like no js browser etc).

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