Hello! Let me write down some thoughts on local sync. With that I mean synchronization of databases which are accessed locally with SyncEvolution backends. This is in contrast to "normal" sync, where one side is covered by a backend and the other side is a SyncML peer (client or server). Right now, the only way to do this is to setup syncevo-dbus-server +syncevo-http-server on one side and syncevolution --daemon=no on the other. Two peers need to be configured. We could simplify the configuration as follows. In the normal, @default context we define the main databases to be used, for example Evolution. No change compared to what is done so far. For those not familiar with the concept, a "context" holds a set of peer-independent source settings (like which backend and database are used for each source like "addressbook"). In another context, say @xmlrpc, we define a sources that accesses different data via some other backend, like the XMLRPC interface. Let's assume we have one source defined, like "calendar". Now we configure one peer "xmlrpc" in the @default context: syncURL = local peerIsClient = 1 [calendar] URI = calendar@xmlrpc When we run a sync, we treat one side as the "SyncML server" and the other as "SyncML client". For performance reasons (more operations done there) it is desirable to have the truly local data being used by the server side. In terms of logging, one option is to use one session directory like this: xmlrpc-2010-06-17-13-00: calendar.after calendar.before calendar(a)xmlrpc.after calendar(a)xmlrpc.before syncevolution-log.html syncevolution-log_trm001_001_outgoing.xml ... syncevolution-log(a)xmlrpc_trm001_001_outgoing.xml status.ini status(a)xmlrpc.ini This requires a lot of changes, both for writing it like this and for accessing the information about the @xmlrpc status and backups. It probably cannot be done without D-Bus API extensions and new command line options. The simpler solution is to have two session directories, one for the server (xmlrpc-2010-06-17-13-00) and one for the client (@xmlrpc-2010-06-17-13-00). When running a sync with the @xmlrpc calendar source as client, some way of storing persistent state is needed. Normally this is done via the per-peer .internal.ini file. The @xmlrpc context doesn't have per-peer directories, but we could put the file into the @default configuration tree as peers/xmlrpc/sources/calendar/.internal-calendar(a)xmlrpc.ini, where calendar@xmlrpc is the URI of the pseudo-peer. That allows changing that parameter without accidentally running a sync with the wrong change tracking state. Removing the xmlrpc@default config would also remove this file. Now regarding actually running two sync sessions. One option is to put the server into the syncevo-dbus-server (as it is now) and the other into a forked process. The advantages of this solution are: * allows using backends with conflicting library requirements (think KDE and Evolution with different setup of glib/libical, etc) * a crash on one side can be detected by the other * no need to get rid of global variables (there are a few, related to logging and finding the context inside Synthesis plugins) * no need to change signal and event handling Drawbacks: * we are forced to serialize messages and exchange it via IPC mechanisms (sockets, shared memory); inside the same address space we at least have the option of skipping SyncML message encoding/decoding if and when the libsynthesis engine gets refactored to pass changes in its internal format directly back and forth * cannot write one common log file The other option is to run everything inside the same process and do a global context switch between the two sides. Currently I favor the idea of using two processes, mostly because it requires less rewriting of code. Loading conflicting backends would require further changes, because right now *all* backends are loaded to register them. Splitting backends into a general-purpose registry library and the actual implementation would be possible, or we could go for the more traditional method of defining backends in text files. I'll let this idea sit for a while, but might come back to it soon. -- 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.