Hello! Let me do a little "thinking aloud" here... please chime in, otherwise I'll start to feel very sad and lonely. Cheers from the sideline are also welcome ;-) One D-Bus API which has been discussed fairly well is the Connect() method for incoming connection requests. It starts a new session under the hood, which is something that the GUI should be able to notice and visualize. As mentioned before, only one session at a time is currently practical (avoids issues with concurrent access to data, internal EvolutionSyncClient API limitations). Should we allow concurrent operations, like listing past sessions, config modifications or data restore? I don't think so. Some of these operations might be safe to execute in parallel to a running session, but this can be tricky to determine. Clearly modifying the configuration of an active session isn't possible, but even just reading old session logs suffers from a race condition: the number and content of old sessions can change as the current session expires old logs. I therefore suggest that we model the new API and implementation around "locking" of a server configuration. Each lock request creates a org.syncevolution.sync interface instance on D-Bus. That instance remains active as long as it has clients or a sync is running. Clients can disconnect and reconnect to such an active instance. In that sense they are not exclusive. Communication between the instance and clients is 1:n. The instance sends out information to all clients as signals. Some of these signals might provide progress or status information. Others might request feedback, like for example a confirmation question ("Do you really want to erase all local data?"). The server needs to know how long it should wait for a reply before proceeding with some default operation. This depends on the kind of clients which are connected: with no client connected, it should wait for a certain amount of time, because a client might show up. With just the command line client connected, it should proceed immediately because that client is not going to ask questions (at the moment...). With the sync-ui connected, it should wait for the sync-ui forever. Clearly the clients need to declare how they are to be treated. The server needs to arbitrate this decision process, because clients have no knowledge of each other. For example, the command line client must not simply ack all questions immediately, because that would prevent the sync-ui from doing any useful user interaction. Locking a config can be rejected immediately or queued, depending on what the client wants. An incoming connection request would be queued. Locking requests can be removed by clients, time out or become obsolete when the client disconnects unexpectedly. Lock requests and running syncs are really the same object, just in different phases, so they should have the same interface and same D-Bus path. I suggest org/syncevolution/sync/<ID number>, with <ID number> being unique (start time plus running counter). Phase changes of these instances need to be signaled so that a client can notice when some other client has started a sync. This sounds rather abstract at the moment. I could move forward with specifying the API, but first I'd like to give a chance for feedback. There are also some other open questions: * Is it okay to transfer sync reports as string->string dictionaries? Example below. * The current GUI API exposes some parts of the configuration, but not all of it. I'd like to switch to a "read key/value dict", "update specific key", "write dict back" model. The value here could be either a single value or a pair of comment+value. The later is more complex and I'm not sure whether the (unlocalized) comments would be useful for any client at all. Here's the current status.ini style format for sync reports. Using a dict removes the need to parse the file. New information can be added without breaking the API. start = 1250597114, 2009-08-18 14:08:14 +0200 end = 1250597121, 2009-08-18 14:08:21 +0200 status = 200 source-addressbook-mode = two-way source-addressbook-first = false source-addressbook-resume = false source-addressbook-status = 0 source-addressbook-backup-before = 623 source-addressbook-backup-after = 623 source-addressbook-stat-local-updated-total = 2 source-addressbook-stat-local-any-received = 562 Most of this is almost self-explanatory, expect for the (ab)use of stat-local-any-sent/received for number of bytes. A full documentation must become part of the API anyway. -- 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.