Re: SDshare push

* Lars Heuer
> 
> Now I am completely lost. Why do you put the fragments into an Atom
> envelope if B has no feed?

For the same reason that normal SDshare uses Atom: it gives us a ready-made XML format to use for the envelope that does exactly what we need. The alternative is to develop a custom format.

> Your use case seems to be "issue an update of the topic map at B". You
> don't need SDShare at all.

What I want is exactly what SDshare does, except I can't use it because of firewall issues. So I need to reverse the normal client/server roles, but otherwise it's really the same protocol. So why not use it?

It's true that I could define and use something simpler, but SDshare is more powerful (ie: covers more scenarios) and I already have it implemented.

> If neither A nor B needs a feed, I don't understand what the proposal has in common with SDShare

Well, A and B don't absolutely have to have feeds as such in normal SDshare, either.

> aside from reusing the TopicSI/TopicSL elements and the fragment update
> algorithm. Given that, I think that the proposal solves a special
> use-case and should not belong to the core spec. of SDShare.

It solves the (quite common) use case where the recipient cannot connect to the source. It also enables a number of new use cases that normal SDshare cannot do.

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