Re: SDshare push

* Graham Moore
> 
> I think posting the batch to some 'transactions' or 'jobs' endpoint on
> a collection would work well.

Yes, essentially that's what the endpoint would be.

> If you include the atom entry uri of the pushing node (i.e. if the
> server were to become the client it could use this URI to fetch the
> atom entry that is the change) on each fragment.

Hmmmmm. One could do that, although if the batch contains the entire fragment I'm not sure what the point is.

> This would allow an error response to be tied back to a failing fragment.

Yes. This seems rather complex, though. Wouldn't submitting fragments individually be simpler? 

> Also, when the transaction is posted then it would be nice if the
> processing of the fragment could run async. The initial response is a
> URL to the transaction status resource. This resource can say
> something like 'Queued', 'In Progress', 'Failed'. It can also have a
> link to a processing report that can contain information such as which
> fragment failed using the fragment Uri above. It can also be used by a
> client to audit what it has sent if needed.

You could do this, but I'm not sure what the benefit is. Having thought about it I think the 200 OK need only be interpreted as "I've received this fragment, and will not forget it". Whether it gets applied right away or later (or not at all, because it's only an aggregator) is up to the recipient.

Of course, it may be useful to be able to introspect the recipient, but I'm not sure I can see that it's any use to the source to be able to do it automatically. After all, if it fails there's not a lot the source can do. So some interface (a log or whatever) for human use may be the most useful and least complicated.

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