[Syncevolution-issues] [Bug 6376] sync-ui + D-Bus server: implement interactive password requests

(In reply to comment #4) > > There's one problem here: what if such a different event (Session::Abort(), new > > data to process from a connection) causes DBusServer::handleInfoRequest() to > > return? There's no way how the caller can resume waiting for a response or tell > > DBusServer that the response is no longer needed. Additional API calls would be > > needed for that. > That's right. A series of APIs may be provided without blocking and a 'wait' > API is used to let callers blocked. > > Perhaps it would be simpler to not make DBusServer::handleInfoRequest() > > blocking in the first place and design the API so that an info request is > > started, checked and cancelled without blocking? > Some initial APIs are provided here(arguments may not be accurate): > string infoRequest(key, parameters) /// start a info request, no blocking > int check(id) /// check whether it is ready, no blocking > void getResponse(&response) /// get response if ready, no blocking > void cancel(string id) /// no blocking > int wait(id, &response) /// wait until response is gotten, int indicates > timeout or other Can we drop the wait() call and go fully asynchronous? When starting the infoRequest(), register a callback that is called and then let responses be handled inside the existing main loop handling.

Why introduce a "string id" when we can return a proper class with member functions? The destructor of that class then should have the effect of canceling the request. That way the owner of that instance can use the normal "resource allocation is initialization" idiom and doesn't have to take care about calling cancel() in error cases.

Regarding having multiple requests active, wait() as suggested above blocks for one specific info request.