Re: SDshare push

* Graham Moore
> 
> It would be cleaner in an error log to say fragment X failed for
> reason Y rather than fragment (complete fragment value) failed becuase
> of reason Y. It provides some identity to what you are doing.

Yes, I agree.

> The value of being able to batch them up would be to know that they
> had been applied as one transaction.

True. Which may or may not matter. In the use case I have in mind the atomicity of batches wouldn't really matter. And, I guess, if it does matter you could always use bigger fragments.

> Seems a bit weak. If 200 OK means I won't forget it but then an error
> occurs how would the sender ever know this?

True. They wouldn't. I suppose you could always fail on the first batch/fragment you receive after a failure has occurred, but you'd then need some additional mechanism to indicate which batch/fragment was the cause of the real error.

> Right but even for a pusher to write an error to some event log or pop
> up a big red screen they need to know that something has gone wrong.

Yes. I meant an event log on the recipient side.

> I agree the simplest approach would be to post each fragment to an
> endpoint and 200 OK to mean I have processed it / committed
> successfully. However, I think that the transactional properties of
> the batch and async with status are useful and don't add much
> complexity.

In my original proposal there would have been the additional complexity of the extra XML format. If we add a status resource for each fragment that does add up a bit.

However, if we post Atom feeds (as described in my response to Kal) and return the status code for each POST with enough identity information for the source to know which fragment failed then I think the additional complexity is very minor.

So perhaps this is the way to go.

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