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

http://bugzilla.moblin.org/show_bug.cgi?id=6376 --- Comment #9 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-12-16 19:03:19 PST --- After reviewing some other implementations in our code, it seems that I have to provide 2 APIs - 'check'(non-blocking mode) and 'wait'. 'check' is to let callers of InfoRequest to check the response arrives. It iterates the source list of main loop. also it gives an opportunity to dispatch events for other sources.(iteration might be removed if regular callback is setup. see below) 'wait' is to let callers of InfoRequest to poll the source list and blocked until the response for the required request. Currently there are many sources, which depends on this kind of mechanism for waiting for events(transporting related, might be more in dbus server). After reviewing the code, I have a concern. In my opinion, when doing sync, the events from dbus clients dispatched mostly are depending on m_agent->wait() in the SyncContext->doSync(), which is, of course, an implicit side-affect. I'm afraid that we should give a regular callback provided by cmdline or dbus server and call them regularly in our Sync main loop. BTW, after discussion with Congwu, we found a potential issue for glib main loop on transporting agents. If aborting happens by dbus clients, obex transporting agent has to wait for at least one response of obexd and then aborting will be handled but for http agent, it would be handled without this kind of blocking. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.