Re: HTTP writing

["Michael Terry" <mike mterry name>]

Hello!

On Sat, Apr 12, 2008 at 8:15 AM, Christian Kellner <gicmo xatom net> wrote:
>  Doesn't S3 have support for directories? And if so, can you delete them
>   by doing a "DELETE" call?

Not really, natively.  It just stores keys for files, and you can
enumerate on the keys using a separator to treat them like a hierarchy
(e.g. by enumerating with the '/' separator).

As a result, my backend would need to handle the rmdir case (and
mkdir) separately anyway.  I was just suggesting that DELETE be put
into the HTTP backend since it seemed like it belonged there, but see
below for my retracted opinion on that.  :)


>  > Or is preventing a non-empty-directory-delete so important from a user
>  > POV that you don't want to leave it up to the HTTP server handling the
>  > DELETE? (though I suspect any server handling it would fail on such a
>  > request, as they probably naively make system rm calls that would
>  > fail)
>  Yes it is that important since we guarantee that in the gio client API.
>  From the API docs of g_file_delete (): "Deletes a file. If the file is a
>  directory, it will only be deleted if it is empty." I know that some of
>  those semantics are a pain for webdav but that's the way it is. We also
>  can't rely on server bugs, i.e. that they only call rmdir (2).

Alright, well, then I withdraw my suggestion for DELETE.  The
semantics of the HTTP method don't guarantee anything really, and
there's no way to ask the server if there are any 'child' URLs of the
request URL.  (Naturally, since HTTP doesn't really truck with
directories, just arbitrary string URLs.)

So, forget DELETE.  But HTTP's PUT semantics do seem in line with what
gvfs expects for create/replace calls.  Again, the DAV code for
create/replace don't make any DAV-specific calls.  Just HEAD and PUT.


>  > If DELETE is a problem, I'm fine with leaving it out of the HTTP
>  > backend.  But moving the writing support in is very useful, and
>  > doesn't depend on any DAV calls.
>  I am all for sharing code, and a little vfunc doesnt seem to be a big
>  problem, I am not sure why you seem to be so against it. You will need
>  some kind of stat call for query_info() and enumerate() anyways. Also
>  having that might it make possible to share code for upload as well.

I didn't mean to appear against it.  I think I was/am confused by what
you mean.  When you say a 'stat virtual function' you're talking about
a method that would give more info than just try_query_info
(crucially, how many children a directory has), be callable by the
HTTP backend in generic delete/enumerate code, and be overrideable by
backends like S3 and DAV?

If so, I think confusion occurred when I assumed 'stat' meant
something akin to try_query_info, which the HTTP backend already had.
I dig your suggestion, though if create/replace could be put into HTTP
directly (since it doesn't really need above stat support), using a
stat virtual function for just delete/enumerate may not be worth the
trouble.


>  On a different note: Does S3 have support for locking files/direcotires?

No, it doesn't.  When PUT'ing to a URL, the last PUT received is the
one that wins.  That *seemed* to me like how gio would want it.  How
is such support handled in gvfs?  I didn't notice a method for
exclusively locking a file in the backend methods.

Thanks for your help,
-mt