On Tue, 2009-09-01 at 14:12 +0100, Jussi Kukkonen wrote:
> Ok, tried to incorporate the comments you guys gave. I chatted with
> Patrick and we came to the conclusion that we should be able to get rid
> of the synthesis signal altogether by having to signals (Status and
> Progress) ... I'm going to look through the sync-ui code for any gotchas
> but I think this is true, and have updated the API proposal.
>
> I'm still not too fond of the current GetReports idea (using hash keys
> like "source-addressbook-sent") but I've tried and can't come up with a
> proposal that would have the same features and a sane API. It'll do.
>
>
> Changes:
> * Sync() now has the forgotten "mode" variable for sources
> * renamed SessionReady to SessionCreated, because that's what it is.
> Moved session.Close() to server.CloseSession() so it can be called
> before the session is actually created.
I like the previous version better: a session will exist in the server
as as soon as StartSession returns. It just won't be ready to execute
any of its methods, except for Close(). I suggest we revert to the
"SessionReady" signal and Session.Close().
> * progress signal reworked: signal "Status" is for sync and source
> status changes and "Progress" includes the whole known progress state
> for the sync. There are matching Get-functions for both.
> * config functions now have a BOOLEAN variable "template"
> for accessing templates. Note that the functions in the session
> interface refer to the server specified in StartSession, so creating
> a config from template looks like this:
> server.GetConfigs(true)
> // pick a template here ...
> config = Server.GetConfig("chosen_template", true)
> // modify configuration here ...
> session = server.StartSession ("my_config")
> // wait for SessionCreated here...
> session.SetConfig(false, config)
> session.Close()
> Sound sensible?
What's the purpose of the SetConfig() template parameter?
> One could also start the session earlier if that
> makes more sense in the client.
I think it makes more sense.
> org.syncevolution.Session
>
> Sync
> STRING mode
> in ARRAY of STRUCT (STRING sources, STRING mode)
>
> [NOTE: valid values for mode are same as in syncevolution config.
> If array is non-empty, only the sources included will be synced.
> If mode is empty the value from configuration will be used]
Did you see Frederik's API proposal for this (using a dict and
additional rules)? I think that extra flexibility is useful.
> GetStatus
> out STRING status
> out INT32 error
> out ARRAY of STRUCT (STRING source, STRING status, INT32 error)
>
> [NOTE: valid values for status:
> "idle","running", "aborting", "suspending", "failed", "done"]
Some sources can be already done while others are still running. Once
the client is in "aborting" and "suspending", so are all sources unless
they already completed.
> GetProgress
> out INT32 progress
> out ARRAY of STRUCT (STRING source, STRING mode,
> INT32 prepare_current, INT32 prepare_total,
> INT32 receive_current, INT32 receive_total,
> INT32 send_current, INT32 send_total)
progress: 0-100%
-1 indicates "unknown value"
> SetConfig
> in BOOLEAN template
> in DICT (STRING source, DICT (STRING key, STRING value))
> UpdateConfig
> in BOOLEAN template
> in DICT (STRING source, DICT (STRING key, STRING value))
>
> [NOTE: outer dictionary contains a dictionary for every source and
> one dictionary for server config]
See above - what's the meaning of "template" here?
--
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
