Re: Protocol Additions in Atomojo

["Alex Milowski" <alexml@xxxxxxxxxxxx>]

On Sun, Jun 15, 2008 at 7:03 AM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> Alex Milowski wrote:
>> 2. Moving and copying media resources.  I've implemented the MOVE and
>>    COPY methods on media resources that use the 'Slug' header to
>>    designate the target.
>
> Why do you use the Slug header field instead of the Destination header
> field?
>
> http://tools.ietf.org/html/rfc4918#section-9.8
> http://tools.ietf.org/html/rfc4918#section-9.9
> http://tools.ietf.org/html/rfc4918#section-10.3

Hmmm... no good reason.  I kept the Slug header because it is the same
header used when creating a media resource in the APP.

While these methods are shared with WebDAV, I had lots of trouble trying
layer WebDAV over the APP in Atomojo and I just gave up at a certain point.

In the end, I only really wanted COPY and MOVE to handle manipulating large
media resources (e.g. video) on the server.

I also came to the conclusion thar a "finder" or "file explorer"
client could just
as easily understand the APP as it does WebDAV.  As such, there isn't a
reason (other than existing support) to do both through the same implementation.

That is, for example, if you're running Apache, you can easily run one
module to run webdav and another to run the APP to manage the same set
of media resources.  That works the same for Atomojo.  Atomojo uses the
Restlet engine (see http://www.restlet.org) and so you can run Atomojo
side-by-side with a WebDAV restlet to manage the same set of resources.

> How do you deal with optimistic concurrency for the destination? Example:
> 'copy this resource if the source has ETag "x" and the destination doesn't
> exist.'

I don't required the use of ETags but that would be easy to add as Atomojo
supports them for other requests.

If the designation exists you get a conflict response status code and
the operation
fails.


--Alex Milowski