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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
