Re: SDshare push

* Robert Cerny
> 
> You might want to distinguish between client (4xx) and server error (5xx), e.g if the feed has syntactical errors the client should be informed accordingly, most likely with a "400 Bad request".

True. I guess the best way to change is to say that 200 indicates success, while any 4xx or 5xx response indicates failure.

> In addition a distinction between "200 Ok" and "202 Accepted" might come in handy. A 202 response could contain a body with a pointer to a processing result document, so that the pushing client can poll the processing status from the server, since he might be interested in how it goes.

We could do this, but don't we then need to define a processing result syntax? If we don't define the syntax, is there any additional value in mentioning 202?

> I realize that the push protocol brings up one question: what happens if there is more than one update at the same time. I am not sure if SDShare takes care of that, since it probably considers only *one* state during the update. This makes everything more complicated, doesn't it?

I don't see how this complicates anything. Let's say two changes both happen at 2011-01-28 14:22:02. It's up to the source to ensure that both changes eventually make it to the recipient. SDshare doesn't concern itself with how this happens, so long as it *does* happen.

> I am not sure how scaleable this solution should be, but i think it is mostly here to push replication data from one master to a slave.

Correct.

> I have a hard time imagining a solution that will scale to internet level with lots of clients, in this case updaters, nor is this the intention of this spec. Am i correct?

You're right that it wasn't the intention, yes. Whether it would work or not I think depends less on the protocol than on the implementations and the inherent difficulties in getting so many different parties to produce a coherent data set.

> If so, it might be beneficial to disallow the simultaneous accepting of requests, by sending an appropriate response "503 Service Unavailable" while an update is going on.

Why? Of course, there could be transactional conflicts between such requests, but isn't that something implementations should handle? Or, if they can't handle it, they can respond with an error and let the source try again? I'm not sure the spec needs to get involved with this.

> One more comment: This spec seems to be fairly independent of SDShare. Did you find anyone one else out there trying to push ATOM feeds?

I think CMIS does it, as does APP (as you'll have seen by now :). 

While implementing an SDshare push recipient just now the same thought did strike me. However, it is bound to SDshare in that we chose to

  (1) use Atom (with SDshare extensions) as the payload format.
  (2) use the SDshare update algorithm.

But other than that, and especially if we were to push individual XTM fragments, it's really in many ways just an "update this topic" service.

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