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. 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.
Best Regards,
Beat
Hello!
I think items that get deleted at the start of a refresh-from-server
sync should be counted as part of the overall sync statistics. Otherwise
we end up with a refresh-from-server sync which doesn't change anything
but claims to have added items.
We have an open issue about that in SyncEvolution:
http://bugzilla.moblin.org/show_bug.cgi?id=3314
Originally I thought that this was caused by SyncEvolution, but after
checking the call stack, I see that it is the DB API DeleteSyncSet()
call (or its internal fallback) which remove the items without counting
them.
That call is defined as:
/*! This routine deletes all datasets from the database
*
* @param <aContext> The datastore context.
*
* @return error code
* - LOCERR_OK ( =0 ), if successful
* - LOCERR_NOTIMP ( =20030 ). For
this case, the engine removes all items directly
* - ... or any other SyncML error code, see Reference Manual
*/
_ENTRY_ TSyError DeleteSyncSet( CContext aContext );
If we add a retval (= DeleteSyncSet(CContext aContext, int
*aNumDeleted), then we change the API and thus must introduce it as an
alternative DeleteSyncSetCounted() (or something like that).
I considered returning the number of deleted items as negative error
values, but TSyError is defined as uInt16 and changing that might change
some ABIs. It's hackish anyway.
Any comments? Is fixing this worth an API change, if so, when?
--
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
