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

> 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

however, there is still a problem here. Like you said, when one caller is waiting, if other events arrive, and their handlers make loop quit. How to deal with it?

> Also, only one info request can be pending at any time. This is probably a > valid simplification, but could be avoided by introducing a handle for it which > is passed around via smart pointers. Destructing the handle would automatically > cancel the request, which is in line with treating a pending info request as an > active resource. I don't quit understand this sentence. so we could allow many requests a time since the above non-blocking APIs.