Re: SDshare push

Any reason why you couldn't use PuSH [1] ? Seems like it would
separate the concerns of fragment production and fragment distribution
nicely.

Cheers

Kal

[1] http://code.google.com/p/pubsubhubbub/

On Wed, Dec 15, 2010 at 1:57 PM, 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
>



-- 
Kal Ahmed
Director, Networked Planet Limited
e: [email protected]
w: www.networkedplanet.com
t: +44 1865 811131