Re: SDshare push

Hello Lars,

I think the spec is implementable as is, but maybe you still find my comments below useful. 

Am 05.01.2011 um 14:34 schrieb Lars Marius Garshol:

> The server must produce an ordinary HTTP response, with a status code
> indicating the outcome of applying the feed. 200 is used to indicate
> no failure, while 500 is used to indicate that there was an error.

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

> If there is an error applying a specific fragment, the server's 500
> response should have a content-type of "text/plain" and the content of
> the response should be the value of the <id> element of the <content>
> element wrapping the fragment.
> 
> Note that servers may apply fragments asynchronously. In this case,
> once the asynchronous thread applying fragments fails, all POST
> attempts will result in a 500 response until the error is resolved.
> All responses will thus contain the same ID, and it is possible for a
> POST request to receive an ID which is not from the feed POSTed, but
> from an earlier feed, possibly POSTed by another source.

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 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. 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? 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. This would also make it necessary to 
 generally determine the availability of the service before assembling the ATOM feed, by sending a HEAD request to the endpoint.

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?

Best regards,

Robert Cerny

Software Development
www.cerny-online.com