Re: Re: Re: Re: Re: Conduit and google synchronization
- From: "John Stowers" <john stowers gmail com>
- To: bielcardona gmail com
- Cc: Conduit <conduit-list gnome org>
- Subject: Re: Re: Re: Re: Re: Conduit and google synchronization
- Date: Tue, 25 Nov 2008 19:42:35 +0100
On Tue, Nov 25, 2008 at 4:41 PM, <bielcardona gmail com>
> There is no such thing as a "mapping group" in the DB. A group in the DB is just two dataproviders with the same UIDs. This is by design, if you set up a group, sync, and then delete it. Then you setup the same group and sync again, they will resolve to the same elements in the database because both dataproviders will have the same confguration, and hence the same UID.Ok... I see...
So, the process of sync'ing is:
* For each dataprovider, get the list of LUIDs (and modification times?)
* Compare each of them with those stored in the database
* Decide what to do with the changes
For each pair in a "group",
1) get the UID of the source and sink.
2) Get all expected LUIDS for that pair of UIDs.
3) Call get_changes on the dataproviders, they should return uids that have been added, modified or deleted.
3b) If the dataprovider does not implement get_changes, then use the DeltaProvider proxy class to fake it by calling call get_all(), and sorting data into added/mod/deleted according to the records in the db
4) get/put/delete the data in the added/mod/deleted lists
The logic for all this is in Synchronization.py (state machines for one and two way sync). The DeltaProvider stuff is in DeltaProvider.py
Hope this helps
Am I right? Maybe you could tell me which peace of code I have to look at to understand this.
][Date Next] [Thread Prev