Ok, I'll write 2 these methods in syncevo-dbus-server and implement them.
> What kind of different return values would be useful and possible? It
> seemed to me that we have just a boolean: no error vs. some kind of
> error. The error would be returned as D-Bus exception, as in all the
> other method calls.
No any other concern but from my experience, exception handling often takes
more than hundreds times of bool value return.
But this should not be an issue of this case.
Cheers,
Yongsheng
-----Original Message-----
From: Ohly, Patrick
Sent: Thursday, September 24, 2009 2:39 PM
To: Zhu, Yongsheng
Cc: SyncEvolution
Subject: RE: [SyncEvolution] D-Bus API: availability of local sources (was:
syncevo-dbus-server implementation)
On Thu, 2009-09-24 at 06:37 +0100, Zhu, Yongsheng wrote:
> > name of the source configuration which defines
> > the backend ("type" property); a temporary config
> > is allowed here
> Since a source won't have many 'evolutionsource' properties in its
> config.ini, I guess
> here we get the available databases by its 'type' properties in its
> config.ini.
> For example, a 'vcard_test' source configuration defines its 'type' as
> 'Evolution Address Book'.
> Then this method returns all available databases for 'Evolution Address Book'
> in the sync source registry .
> Is anything wrong?
That's correct. The reason for requiring a full source configuration is
that possibly some other properties might be required beyond "type".
This is not the case now, but perhaps some yet-to-be-written backends
will add additional properties. The API should be able to cope with
that.
> For CheckSource, why preferring 'throwing exception' to return values to
> indicate results?
What kind of different return values would be useful and possible? It
seemed to me that we have just a boolean: no error vs. some kind of
error. The error would be returned as D-Bus exception, as in all the
other method calls.
We still need to define some D-Bus exceptions as part of the API. Jussi
mentioned some in another email.
--
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
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
