I wrote yeterday:
Hey, sorry for not sending this last week already, I dropped the ball
with other things last week and then enjoyed a sunstroke this week.
A solid 13 hours of sleep seems to help a lot with getting back to speed...
Ok, during a discussion with Patrick yesterday these issues were identified:
* Sync is not the only action that needs locking
* some methods must be callable even when another client has a lock
(think UI starting during an automatic sync)
So, revising a bit: The (possibly badly named) Sync object contains
read-only methods that can be called without a lock and a StartSession
call, which is used when a client wants a lock. StartSession returns a
object path for SyncSession, which has a signal to tell when the lock is
acquired. So there may exist multiple sessions, but only one has a lock.
The SyncSession contains also the read+write methods.
Some of the methods (GetConfig, GetReports) are now duplicated in the
Sync interface and the SyncSession interface... That's not necessarily
needed but I think might make sense to emphasize that you need a
session/lock to do atomic operations, such as GetConfig+UpdateConfig to
modify an existing configuration, but that you can do GetConfig with out
a lock (just don't trust the config to exist on the next call).
Comments?
- Jussi
---
org.syncevolution.Sync
GetConfigs
GetConfig
GetReports
[NOTE: these are also in SyncSession. Here because they must
be available even without a Session (e.g. when starting a UI
when a sync is already in progress)]
StartSession
[NOTE: returns immediately with the SyncSession object path]
GetSessions
signal SessionStart
signal SessionEnd
org.syncevolution.SyncSession
[NOTE: this is e.g. org/syncevolution/SyncSession/<id>]
signal Locked
IsLocked
[NOTE: there can be several syncsessions, but only one is
'locked'. A new session will only become locked when older sessions
have closed]
Close
[NOTE: closes the session, freeing lock if there was one]
Sync
AbortSync
SuspendSync
signal SyncProgress
[NOTE: Progress should include a bit more than it currently does,
maybe even separating into "generic" and "detailed" signals (latter
with raw synthesis stuff, that could be deprecated later if our own
signal became good enough)]
GetConfigs
GetConfig
SetConfig
UpdateConfig
[NOTE: update only modifies the keys that are included,
set rewrites whole config]
GetReports
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
