On Thu, 2009-08-27 at 12:05 +0100, Jussi Kukkonen wrote:
> 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)
Overall this sounds right.
> So, revising a bit: The (possibly badly named) Sync object
org.syncevolution.Server?
> 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.
Client's need to be aware of a race condition:
1. StartSession returns object
2. server locks the session, firing the signal
3. client receives object, starts to watch for the signal
=> client waits forever
So the clients have to watch for the signal and before going to sleep,
check whether they already have the lock.
> 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).
We could get fancy and put the "common" methods into an
org.syncevolution.Query interface which is provided by the
org.syncevolution.Server object as well as session objects, but this is
probably overkill.
> ---
>
> 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
SyncSession => Session? A session is not necessarily always about
running a sync.
> [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
Looks good so far. The next step is to iron out the exact parameters
and return values.
--
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
