Re: SDshare push

Hi Lars,


[...]
> I see what you mean (and I didn't really before). This is actually
> a completely different protocol.

ACK. I haven't seen that either until your msg dtd. Fri, 28 Jan 2011.

> It's not necessarily a bad idea, but it's not what I had in mind
> with SDshare push at all.

ACK.

[...]
> However, that's not what I'm trying to do. I have a production
> server separated from the editorial server by a firewall. I can't
> use SDshare to keep the two in sync, because the production server
> can't connect to the editorial server (where changes actually
> happen). So instead of the production server polling the editorial
> server for changes I want to have the editorial server push changes
> to the production server. (The firewall does allow connections that way.)

I see. So wouldn't APP + PubSubHubbub yield the same result? We could
reuse some (de-facto) standards.

[...]
>> My goal was that the user modify the feed via APP/REST. I don't see
>> how it could be done with SDShare push.

> It couldn't. But then it was never the goal, either. :)

:)

[...]
>> I see. I think that I still prefer one request per fragment since a
>> fragment is a self-encapsulated entity (the result of a successful
>> operation on a topic within a topic map).

> Well, you could just as well have N fragments be the result of a
> single operation. One example is modifying an association. Another
> would be a tolog update statement. A third would be a single
> transaction against a TM.

Right. My response contained a paragraph why a batch update which
represents a TMQL/tolog transaction would fail in both use cases
(obvious vs. batch) but I removed it since I was unsure if it's a
failure in my way of thinking or in SDShare push. :)

I have to think about it; I'll come back to this issue.

[...]
> In your use case that's true. In mine it's not.

ACK.


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