Re: SDshare push

On 15 December 2010 19:50, Lars Marius Garshol <[email protected]> wrote:
>
> * 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.
>

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.

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

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

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

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?

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

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.

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.


> --Lars M.
> http://www.garshol.priv.no/tmphoto/
> http://www.garshol.priv.no/blog/
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>



-- 
Graham Moore, Director, Networked Planet Limited
Editor XTM 1.0, ISO13250 (TopicMaps) -2,-3, TMCL
e: [email protected]
w: www.networkedplanet.com
t: +44 1865 811131
m: +47 90056479   (Norway)

Networked Planet Limited is registered in England and Wales, no. 5273377