Re: SDshare push

Hi Lars,

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

I tend to disagree, the alternative is using APP.

Well, it's true that SDShare uses Atom, but SDShare would have been a
much better specification if it would not depend on Atom; but that's
another story.

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

Okay, understood.

I am still wondering why the proposal invents something new while the
rest of the Atom family (since SDShare made the decision to depend on
Atom) is more or less happy with the existing de-facto standards.

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

Having an implementation is no argument. I guess you won't disagree.

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

Well, I still think that (de-facto) Atom standards will solve the same
problem and aside from "more HTTP requests" I haven't heard any
argument that convinces me to like the proposal.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<https://twitter.com/larsheuer/> Twitter
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine