Re: SDshare push

Hi Lars,

[...]
>> 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 goes on: "Successful member creation is indicated with a 201
> ("Created") response code." Ok, but, again, we're not necessarily creating anything.

I see. Thanks for explaining, I think we've a different view on
updating/deleting (see below).

[...]
>> 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.

I thought a DELETE request to an fragment/a snapshot would remove the
fragment/snapshot from the feed. Let's assume I've the following feed:

   * Fragment 15
   * Fragment 14
        .
        .
   * Fragment 1
   * Fragment 0

If I'd know that applying the fragments 10 - 15 would yield the same
result as applying the fragments 0 - 15, I'd like to delete the
fragments 0 - 9 from the feed to minimize the overhead at the server
and at the client. How could I do that? I'd use the HTTP/APP DELETE
for removing fragments/snapshots from the Atom feed.

My goal was that the user modify the feed via APP/REST. I don't see
how it could be done with SDShare push. The fragments would still be
part of the feed and a client should download the (maybe empty)
fragments/snapshots, if I understood your proposal correctly.

>> 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.

You can do everything with an ordinary HTTP client, but some clients
like the Abdera client provide a convenient interface for Atom. But I
agree that client implementations is not the main argument. The
proliferation and the support for APP (GData, Blog APIs) is IMO an
argument.

[...]
>> 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.

Hmm. I don't see the difference between fragments and snapshots to be
honest.

>> 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.

I see, sorry, my fault.

> 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.

ACK.

>> 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).

I see. I think that I still prefer one request per fragment since a
fragment is a self-encapsulated entity (the result of a successful
operation on a topic within a topic map). Further, I wonder if the
batch mode is more efficient. POSTing a fragment should be possible
due to the size of a fragment, but POSTing 100 fragments may result in
a long delay on the server-side.

To sum it up: I like one request per fragment because of its
simplicity. The client don't have to parse the SDShare-specific
<id>/<content> response body but rely on HTTP (APP) status codes.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<https://twitter.com/larsheuer/> Twitter
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine