Re: SDshare push

Hi Lars,

Sorry for the delay.

>> 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've no idea. To me, if a bunch of changes were done as a single
> atomic operation, it would make sense to transfer them that way, too.

Aside from a feeling that the proposed solution is ugly, I wonder if
this solution works for SDShare clients. SDShare does not mandate that
a "server" must update the feed in a transaction. The server may
publish a feed which provides not all changes issued by a transaction
which initiated the fragment update. The solution may work for
updating a single server, but the synchronization with clients remains
unclear. A client may gather the updates 1 .. n-1 but ignore
(intentionally or not) update n.

I still find one request per fragment + APP more elegant. Aside from
the technical problem, mentioned above, it's maybe just a matter of
taste and a matter of the interpretation of the purpose of SDShare,
though.

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