Re: SDshare push

Hi,

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

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.

> <fragments prefix="...">
>  <fragment uri="http://pushingserver.com/collections/topicmap1/changes/838838683683863>             <-- change entry on pushing node
>    <TopicSI>...</TopicSI> <!-- and sl & ii -->
>    <topicMap ...> <!-- XTM fragment -->
>  </fragment>

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

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.

Gra

On 15 December 2010 14:57, Lars Marius Garshol <[email protected]> wrote:
>
> We have a customer who is interested in the SDshare push protocol,
> basically because they want an efficient way of keeping their
> production server in sync with the editorial server where changes are
> actually made. Normal SDshare cannot be used for this, because the
> production server cannot connect to the editorial server (due to
> firewalls).
>
> To solve this I need to come up with a design for a push form of
> SDshare, since the spec doesn't describe any such thing. Below are my
> thoughts on this.
>
> The SDshare spec talks about "server" and "client", but in the push
> form of the protocol these two roles become reversed. To avoid
> confusion I'm going to use the terms "source" and "recipient". In the
> ordinary SDshare the source is the process which tracks changes and
> produces Atom feeds of fragments, while the recipient polls the feeds
> and downloads and applies fragments.
>
> In SDshare push the roles are reversed: the source pushes fragments to
> the recipient, so in HTTP terms the source is here the client, while
> the recipient is the server.
>
> Here's what I'm taking as given:
>
>  (1) The list of fragments maintained by the source remains exactly
>      the same as in the pull form of the protocol.
>
>  (2) The actual fragments are also the same.
>
>  (3) The fragment update algorithm (in 5.4.4) remains the same.
>
> The only thing that really changes is how the fragments get from the
> source to the recipient. In this push proposal we make no attempt to
> define what causes a fragment to be pushed from the source to the
> recipient. It could be a thread that at fixed intervals pushes any new
> fragments, or it could be human intervention through a GUI, or
> something else.
>
> === The obvious proposal
>
> The most obvious way to do this is to define an endpoint URI and say
> that fragments are POSTed to it, with the following parameters:
>
>  prefix: corresponds to sdshare:ServerSrcLocatorPrefix in the fragment
>          feed in the pull form of the protocol
>  fragment: the actual XTM fragment
>  topicsi: corresponds to the sdshare:TopicSI element in the fragment
>           feed (obviously to be joined by topicsl & topicii in time)
>
> The syntax used should be identified via the Content-type header.
> Unless the recipient responds with HTTP status code 200 the source
> should assume that the posting failed (and retry later, if that's
> applicable).
>
>
> === Batch proposal
>
> The above can potentially mean having to do many POST requests to get
> all changes across. One way to avoid this would be to create a custom
> XML format like so:
>
> <fragments prefix="...">
>  <fragment>
>    <TopicSI>...</TopicSI> <!-- and sl & ii -->
>    <topicMap ...> <!-- XTM fragment -->
>  </fragment>
>  ...
> </fragments>
>
> This could then be POSTed to the endpoint, allowing many fragments to
> be POSTed in a single operation. The benefit is potentially fewer HTTP
> requests. The downside is making the protocol more complex, and also
> that if a fragment fails there is no way to know which one.
>
>
>
> That's it. Any thoughts on this?
>
> --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