Hi Patrick,

in case of two-way-sync the engine always reads all items of the plugin with a sequence of ReadNextItem until eof. So the engine knows about the number of elements.

In case of refresh-from-server and availability of DeleteSyncSet, reading the items is not needed, because the elements will be deleted anyway.
But the number of items is not known for this case.

The difference in performance is marginal if your implementation of DeleteSyncSet just goes thru the list of your items and deletes them item by item, the overhead by returning 20030 and let the engine delete element by element (but knowing then how many elements are deleted).

The only difference is mainly reading the sync set (which must be done for all two-way-syncs anyway). The performance difference is huge, if you have just one command to delete all elements, which is e.g. the case for our iPhone client. But I'm not even sure if this command would return the number of deleted elements.

Best Regards,
Beat


On Tue, 2009-07-28 at 13:13 +0100, Beat Forster wrote:
 Hello Patrick,

 my opinion is that this is not worth an API
 change. DeleteSyncSet always expects to remove
 all elements of the sync set, a return value
 different to this is anyway not allowed and might
 be interesting for statistics but in all other
 cases very confusing.

Yes, that's also what I thought. My last sentence should have said "API
extension", like DeleteSyncSetCounted(). Do you also think that this is
not necessary?

  Usually the engine knows
 about the number of elements in the sync set,
 therefore no additional information is needed to
 get this count.
 In case of a refresh-from-server I assume the
 sync set will not be read, but the plugin could
 return 20030 if no ReadNextItem sequence has been
 done before. So the engine will remove element by
 element then and get the number of elements this
 way.

I'm not sure I follow here. Suppose a database plugin implements the
current DeleteSyncSet(). How does the engine know how many items were
deleted? Is it possible without causing overhead (the main reason for
the existance of DeleteSyncSync(), I suppose)?

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis


--
-----------------------------------------------
       Beat FORSTER
       Dipl. El. Ing. ETH
       Dipl. NDS ETHZ in Betriebswissenschaften
       Managing Partner
       beat.fors...@synthesis.ch

Synthesis AG   SyncML Server & Client Solutions
Badenerstrasse 18,  CH-8004 Zürich, Switzerland
Tel (direct):       +41 44 440 66 02
Fax:                +41 44 440 66 04
email:              i...@synthesis.ch
web:          http://www.synthesis.ch
-----------------------------------------------

_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to