Re: SDshare push

* Lars Heuer
> 
> 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.

I see what you mean (and I didn't really before). This is actually a completely different protocol. It's not necessarily a bad idea, but it's not what I had in mind with SDshare push at all.

If you consider an SDshare feed to be a kind of Atom-based blog you could definitely use APP to modify that remotely, and I agree that for this use APP would be ideal.

However, that's not what I'm trying to do. I have a production server separated from the editorial server by a firewall. I can't use SDshare to keep the two in sync, because the production server can't connect to the editorial server (where changes actually happen). So instead of the production server polling the editorial server for changes I want to have the editorial server push changes to the production server. (The firewall does allow connections that way.)

So the editorial server is not actually operating on an SDshare server with APP-like requests, but simply notifying a different node about local changes. For that, simply POSTing an Atom feed with inline content seems ideal to me.

> My goal was that the user modify the feed via APP/REST. I don't see
> how it could be done with SDShare push.

It couldn't. But then it was never the goal, either. :)

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

Now that I know what you are talking about, neither do I. When I wrote that I could see how you might use APP to modify the snapshot feed of a server. It didn't occur to me that anyone might want to remotely modify the fragment feed, since that's a record of the changes that have happened on the server, and not an arbitrary set of XTM files like the snapshot feed.

But if you really do take the point of view that you want to maintain a set of SDshare feeds on another server, then APP is ideal, and the two use cases become the same.

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

Well, you could just as well have N fragments be the result of a single operation. One example is modifying an association. Another would be a tolog update statement. A third would be a single transaction against a TM.

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

True. However, the time spent processing that 100-fragment request should be roughly the same as processing 100 single-fragment requests. However, for the latter you also get the overhead of 99 extra requests (and potentially TCP connections).

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

In your use case that's true. In mine it's not.

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