[Syncevolution-issues] [Bug 6376] sync-ui + D-Bus server: implement interactive password requests
http://bugzilla.moblin.org/show_bug.cgi?id=6376
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 2009-12-17 01:55:21 PST ---
(In reply to comment #11)
> > BTW, after discussion with Congwu, we found a potential
issue for glib main
> > loop on transporting agents.
We really should move this discussion into a separate issue... ;-}
> > 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.
>
> "obex transporting agent" = DBusTransportAgent? There is a "TODO:
setup regular
> callback" in DBusTransportAgent::wait() about that - not filed in Bugzilla
yet,
> though.
No, it's ObexTransportAgent.
Well, obexd was mentioned. ObexTransportAgent is not guaranteed to talk to
obexd, while DBusTransportAgent currently is.
There are 2 issues:
[...]
2) There is a timeout function to check whether to abort or suspend
the sync
though checking the global flags(internally set by signal handler). However,
dbus server might receive 'abort' events from server and sets them in
DBusSync.checkForAbort/checkForSuspend callbacks. SyncContext will regually
call it. So for this, ObexTransportAgent has to wait for at least one response
from OBEXD. This is not so reasonable. ObexTransportAgent timeout function
should invoke checkForAbort/checkForSuspend instead of arbitrarily reading
internal global flags.
There's one more issue: should a suspend request abort transports at all? Our
logic so far was that suspending takes place after receiving a reply. See
mailing list email.
(In reply to comment #12)
I think the problem is: abort from dbus clients do not (and should
not?) set
the global flags (SuspendFlags, AbortFlags), however all transport
implementation only checks this flags instead of calling the virtual method
(checkForAbort/checkForSuspend). Therefore abort from dbus clients will not be
visible to transports (Not Obex specific).
To cope with this, we need to pass the SyncContext instance to Transport and
calling checkForAbort/checkForSuspend instead of checking the flags directly.
Sounds reasonable, with one tweak: instead of getting access to SyncContext,
transports should check state via a new virtual interface (InterruptState?
Better names welcome.) that is implemented by SyncContext.
--
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.