On Wed, 2009-09-02 at 14:30 +0100, Jussi Kukkonen wrote: > This thread never just never ends... I've written the service definition > xml and while doing that found still several things to change. Sorry > about that, please bear with me. > > Service definition: http://folks.o-hand.com/jku/syncevolution/syncevo2.xml > > Documentation: > http://folks.o-hand.com/jku/syncevolution/index.html > > > Unresolved issues: > > * Do we want to implement the temporary configuration Patrick suggested?
Yes, but I've already said that ;-) Any other opinions? > * anything else I may have forgotten? Do we want to reserve the right to add more detailed information about "processing" and "waiting", in other words, request that clients be able to handle "running:waiting:foobar"? We don't have to use it, only document it and write our clients accordingly. > Changes: > > * GetConfigs: add string params for web url, icon uri and description > and boolean consumerready. Description is new compared to existing > api. I assume this is to simplify the application startup. Clients could get this by requesting detailed configuration information, right? The drawback is that the API becomes very much tailored towards HTTP servers. Any kind of additional information that we might need in the future (Bluetooth device identifier, category of such a device, ...) will require changes to the API. Requiring that clients read the configs to get this information doesn't suffer from this problem, because the hash is extensible. Do we really need this? > * SessionEnd renamed to SessionChanged (with boolean started) > > * Removed Ready signal altogether (see below) > > * StatusChanged and GetStatus: I tried to take the latest discussion in > to consideration and modified status values: > "not-ready": no 'lock' yet (better name suggestions?) "queued"? But that might be to implementation specific. > "idle": doing nothing, see error to check if last call succeeded > "running": Doing something. source specific status are valid. > "aborting" > "suspending" > These values are valid for specific sources when the generic > status is "running": > "idle" > "running" > "done": source has been synced even if whole sync continues > Valid modifiers for statuses, e.g. "running:processing" or > "suspending;waiting": > "processing" > "waiting" Minor typo in "suspending;waiting", but apart from that okay. > * remove UpdateConfig, add boolean flag to SetConfig instead > > * renamed signals Status->StatusChanged, Progress->ProgressChanged > > * ProgressChanged and GetProgress: Added a string param 'phase' to the > source progress structs: "preparing","receiving","sending" or "". > > * ProgressChanged and GetProgress: Moved sync mode to StatusChanged and > GetStatus. I think it makes more sense as state than progress. Agreed. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Hermuelheimer Strasse 8a Phone: +49-2232-2090-30 50321 Bruehl Fax: +49-2232-2090-29 Germany _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
