[tahoe-dev] proposal for an HTTP-based storage protocol

[Kevin Reid]

On Sep 26, 2010, at 12:03, Ravi Pinjala wrote:

> The trouble with using the xmlns to identify the interface is that it
> complicates parsing a bit - clients have to support separate formats
> for each interface.

Could you explain this further?

>>> * URL of a document stored on the server:
>>> http://server.address/data/foo/bar
>>>
>>> * URL of the metadata for said document:
>>> http://server.address/metadata/foo/bar
>>>
>>> * Example of direct access to a metadata key:
>>> http://server.address/metadata/foo/bar?mtime
>>
>> It should be explicitly part of the definition of the data and  
>> metadata
>> modules that they define these path patterns (underneath the path=  
>> URL).
>
> Mmm, what do you mean? I'm not really seeing what you're saying here.

It's one of the REST principles: the client should never construct a  
URL according to its own rules, but rather only use links and forms  
returned by the service. In this case since the objects are identified  
by pathnames it is natural for the "form" to be "use the pathname as a  
URL relative to the root specified for this interface in the discovery  
document", but this should be explicitly part of the specification of  
these interfaces rather than a global assumption that URLs are of the  
form /<interface path>/<file path>.

I admit this is a particularly degenerate case of this principle, but  
I think following the principle is a good thing in principle. Ahem.

> Do we actually need server-side verification of data? We already let
> clients upload whatever they want to servers, as long as it's properly
> formatted as a share.

Yes, but they can't upload something that looks like a share of file A  
but actually contains some other content (unless they find a hash  
collision).

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>