SDshare push

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/