[RFC] drop plugin batch_commit for 0.40?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

first this issue is tracked by ticket #1078.

http://opensync.org/ticket/1078

OpenSync supports two ways of writing changes to a plugin -
commit_change and batch_commit.

The first variant calls a callback for every change and optionally if
requested by the plugin then committed_all callback is called. This
means one callback per change and an optional all changes done callback.

The second variant calls only one callback and submits all changes at
once. All changes still have an own context but all changes are
collected first.

The second variant cause a problem with our IPC message queues. IPC
queues should always be limited in some way. OpenSync uses such IPC
message queues to handle changes and the answers to these changes. Every
change is sent to a queue. If the queue handles the change then the
according handler is called and the pending reply to this message is put
into another queue. These pending replies are limited to avoid too many
waiting IPC messages. So back to two variants. What happens?

The first variant immediately calls a callback for every change. The
change is handled and the context is signalled. If context is signalled
then the reply is present and no longer pending. The IPC queue can
handle the next message (which is a change or the committed_all
message). So the message queue does not block.

The second variant does not call a change callback per change message.
All changes are cached and when the committed_all message is handled
then all change messages are handled at once. If there are more then IPC
queue limit - 1 changes then the queue stops working until one of the
change messages is handled. No change message is handled until the
committed_all message is handled. So there is a deadlock.

Therefore I want to remove the batch commit function. If one change
fails and is already committed then committed_all or sync_done can be
used to signal an error which would cause a new slow-sync.

The SyncML mapping is an open issue.

SyncML/OMA DS clients can send a mapping after the changes from a server
were received. These mappings are first available after the changes are
committed. OpenSync is today not able to handle this after a change is
already committed. So we still need a solution for the mapping.

Best regards

Michael
- --
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482           ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704           Unter den Linden 6
michael.bell@...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ3Ihi2L0ZGCAwWqsRAi00AJ978vdR/pj2vBvKnGnD/LDXnzvRBgCfU93n
h6deJufpf2hnWFpEW0SrGr4=
=8E8j
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel