Re: SDshare push

Apologies for the late answer. I had to put this aside for a while.

* Lars Heuer
> 
> Can you explain that point? I don't understand what you mean with "APP
> expects a new fragment to be created".

Well, look at the text for the APP operation:
  http://tools.ietf.org/html/rfc5023#section-9.2

It says: "To add members to a Collection, clients send POST requests to the URI of the Collection." Well, we're not necessarily creating or adding anything; we might just as well be updating or deleting.

It goes on: "Successful member creation is indicated with a 201 ("Created") response code." Ok, but, again, we're not necessarily creating anything.

Later: "When a Member Resource is created, its Member Entry URI MUST be
returned in a Location header in the Collection's response." Again, we haven't made any member entry in any meaningful sense. Of course, if we're pushing to a server that has an outgoing SDshare feed there might be a URI to retrieve the fragment we just pushed, but that's (a) not a given and (b) usually of no interest to the client, anyway.

So while there isn't a 100% mismatch in semantics, there certainly is substantially less than a 100% match.

> APP provides a service discovery mechanism (which could be optional
> for SDShare) which tells the client which media-types are acceptable,
> which collections are available etc.

This partiular part there might be some value in reusing, or at least mimicking closely. So far SDshare push doesn't contain anything like this, though.

> APP provides DELETE (which we may need later maybe),

Not for SDshare push (where delete is done by pushing an empty fragment), but a DELETE operation might have its uses.

> APP defines the status codes, APP is well known and clients are available for APP.

Yes, it does define status codes, but these don't match the semantics of SDshare, and provide nothing over and above what HTTP defines. Similary, I don't see how you could use an existing APP client to do SDshare push any more easily than you could with a normal HTTP client.

> I know that APP may be a overkill if SDShare mandates that each
> SDShare server must also provide the complete APP, [...]

I agree, but I didn't interpret you to mean that this should be requirement.

> but APP is popular, it's is well known and supported and SDShare could simply define a subset of APP which MUST be implemented by a SDShare server.

We could, but I don't see that we gain anything by doing so. I don't see that you could reuse any APP client or server in any useful way.

> Creation/removal of snapshots could also be handled by APP.

Yes, this bit one could do by using APP, and the semantics would match quite well.

> Maybe I missed something, but I cannot find a discussion if a POST of
> a collection of fragments is necessary vs. POST of a single fragment.

On December 15 I posted two proposals: "obvious" and "batch". The former posts single fragments, the latter a collection. There was then a discussion with Graham regarding which to choose. In the end, inspired by PuSH, we decided to go with batch, but with Atom as the format instead of a custom format.

> Why do you think that POSTing a collection of fragments in a single
> request is useful?

It's more efficient (fewer requests), and it makes it possible to provide atomic updates (either all fragments in a batch are applied, or none are).

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/