Patrick, That is a good idea to control access of server config for multiple clients. I have some questions. > 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. I'm a bit unclear about this paragraph. Here is my understanding. syncevo-dbus-server generates a unique interface for each server configuration. Any client who want to read/write/update it needs to use this interface. In such case, we could apply a lock for this interface to implement a 'around locking' for server configuration. Right? If yes, I have one question: This interface should be generated dynamically. I wonder how this interface is notified to those clients who do not get the signal sent by syncevo-dbus-server? Another issue is that you mention 'not exclusive'. I consider it true only when instance broadcasts status/progress information. Otherwise, like update, it should be exclusive. > 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. What mechanism do you use for finding clients? Using Dbus standard interfaces to get registered DBus connections?
> Locking a config can be rejected immediately or queued, depending on what the > client wants. An incoming connection request would be queued. I want to know what algorithm you use to handle incoming connection requests, First in first serve? Does any incoming connection request has higher priority than others, such as GUI client? > Locking requests can be removed by clients, time out or become obsolete when > the client disconnects unexpectedly. So a client need request a connection before doing any request, like locking? Or if a connection request is accepted, the locking by that client is actually applied? Could you help show me a more detailed general process when a client wants to update or write the server config? Thanks Yongsheng _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
