On Mon, 2009-08-03 at 06:32 -0700, Bob Eggers wrote: > Hi Patrick, > > I have a few questions aimed at trying to understand what I see in the > backend code samples. I've been looking at SyncEvolution 0.8, because > I assumed it was more stable at this point in time.
I'd recommend 0.9 beta 3 at this point. From a user's perspective it has one bug fix which never made it into a 0.8.x maintenance release (regarding notes with only a summary and no description). For a developer it simply is the code base which is under active development. You've mentioned WBXML. That is only supported in 0.9, thanks to the Synthesis engine. > Anyway, my questions are a mix of my possibly false assumptions and > actual questions: > > 1) In the backend, are all the uid parameters local UID's? Yes. > Need we have any concern about mapping to remote ID? No. > Is the engine handling that? Mostly the server does it. There's only one case where the client sees a GUID at all, that's when it is asked by the server to add a new item. The server only has the GUID, so it sends that to the client together with the data. The engine remembers the GUID, combines it with the LUID created by the backend, then tells the server about the mapping. So even in that case, the backend never has to deal with anything other than its own LUID. > 2) listAllItems(): the backend itemizes the entire local store and set > revisions[<localUID>] with last revision stamp or modification time. Correct. This is the concept used by backends derived from TrackingSyncSource, which is the easiest to implement *if* there is a suitable revision/last-mod property. A more flexible backend would derive from EvolutionSyncSource and implement the change tracking itself. > 3) a) createItem(): generate a sync item data blob to ship to the > server, which could be for add or update and we don't need to know? Correct. However, note that the "blob" is treated differently in 0.8.1 and 0.9: in Funambol clients (0.8), the backend is responsible for converting to and from the format expected by the SyncML server. In 0.9, the "blob" is processed by the Synthesis engine and converted into the format supported by the SyncML server. The complexity of that conversion can range from very simple (using different X- extensions) to very complex (iCalendar 2.0 locally, vCalendar 1.0 remotely). This article introduces the conversion: http://moblin.org/documentation/syncevolution/pim-data-synchronization-why-it-so-hard Here's more about the different layers of data conversion in SyncEvolution 0.9: http://moblin.org/documentation/syncevolution/architecture-testing If your local datastore doesn't have a native serialization of an item, then the SyncEvolution API should be changed so that you can exchange individual properties directly with the internal Synthesis format ("field list"). The internal format can already be configured so that it matches exactly what your client supports (important for accurate Device Information). > b) insertItem(): either update or add item to the local store > depending on whether UID already exists locally? That, and whether the caller provided a UID. Without a UID, do an add first. The reason for making this a single call is that in some cases an add must be turned into an update (iCalendar 2.0 meeting was imported into server and locally, backend detects the match based on iCalender 2.0 UID) or an update into an add (only on the server side). > c) deleteitem(): delete item from the local store > Does the sync engine handle deleting items on server based on the > results of listAllItems (UID's detected missing)? Yes. > 4) Our contacts records do not have a last mod time Then it might be more suitable for implementing the EvolutionSyncSource base class. In that class you initialize your data store, then report added, updated, deleted items yourself. The Evolution backends used to work like that based on a similar "change list" kept by the Evolution Data Server. I found that a bit limited, for example, reading that list was destructive (it wasn't possible to just read the list without erasing it). It might be better with your implementation. > a) we are able to get a list of records that changed and > another > list of records deleted since last time we checked > b) if my assumption that items not appearing in the listAllItems > will be deleted remotely by the engine, we can ignore this deleted > list > c) with the changed records list, we could say last mod time is > NOW > (say, the start of sync), and set a custom field in the record to act > as last mod time. (Will have to re-save the record locally.) > d) with unchanged records, do nothing but extract that last mod > time > from the custom field Instead of faking a last mod field it might be easier to implement the EvolutionSyncSource class. > 5) exportData walks through all records and create item data blobs - > presumably this is called in the slow sync scenario? No, slow sync goes through the normal createItem() call to get item data as needed. exportData() (renamed to backupData() in 0.9, to match the new restoreData()), bypasses the conversion into the Synthesis format. This way it can provide a true local backup/restore with as little transformations as possible. Besides backup/restore, it is also used by the client-test test program. You don't have to implement it for sync. > I appreciate your help - maybe these questions have been answered > somewhere already. :) No, not in detail. So it's worth doing this on the list :-) -- 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. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
