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.
General notes about the Connection api:
Do we want org.syncevolution to be just a namespace (in other words
should Connect() be a method of something like
org.syncevolution.ConnectionManager)
Also (I think this was mentioned but I can't find it now), we
probably need signals and methods to monitor connections/sessions.
Comments on the the Sync interface discussion:
Patrick wrote:
> * 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.
These are both the solutions I arrived to as well. It may be somewhat
counter-intuitive in that we're not using the datatype support D-Bus has
but in both cases the pros outweigh that, I think...
The locking/"client type declaration" issues need a bit of thought -- I
hadn't realized the user-input-from-several-client problem... My
original idea was just to have a Session object for the things we want
to keep single-instance and handling the other things (GetConfig,
GetReports) even if there is a Session going on.
I guess the options are:
1:
* clients inform the server of their "capabilities"
* server has signals like ConfirmationNeeded
* clients respond by calling methods like SetConfirmation
2:
* clients who want to respond to queries implement
a new API that has methods like GetConfirmation
* server would either decide which client to ask or asks all of them
This all sounds pretty complex, and requires thought at least...
Anyway this is my idea for the revised .Sync api, written before
Patricks post last week (again, sorry for not handling this better). It
is pretty much compatible with it, as far as I can see.
I'm leaving the signatures out of this post to keep it clean, I'll send
the full dbus spec for .Sync later if this looks ok (unless Patrick
wants to do it).
org.syncevolution.Sync
GetConfigs
GetConfig
SetConfig
GetReports
StartSession
[NOTE: This would implement 'locking' if we only want a single
session]
GetSessions
signal SessionStart
signal SessionEnd
org.syncEvolution.SyncSession
[NOTE: this is implemented by org/syncevolution/SyncSession/<id>]
Abort
Suspend
signal Progress
[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)]
[NOTE: ServerMessage and PasswordQuery are not handled at all..
It is possible that clients that are able to handle them should
implement another DBus api?]
-Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
