dvfs api and toolkits

[Sean Middleditch]

On Sun, 2005-04-03 at 21:54 -0400, Owen Taylor wrote:
> On Sun, 2005-04-03 at 21:34 -0400, Avery Pennarun wrote:
> > On Sun, Apr 03, 2005 at 09:20:41PM -0400, Owen Taylor wrote:
> > 
> > > A synchronous API *must not* recurse the main loop.
> > 
> > I'm pretty sure that's not true of all toolkits.  In some, for example,
> > dialog boxes are implemented by explicitly calling the event loop after
> > blocking certain kinds of events.
> 
> The point is not that the main loop cannot be recursed, but that
> recursing the main loop when the app isn't expecting it will result
> in hard-to-debug, obscure, bugs. A synchronous API must block with
> no side effects until the call completes.

Which is yet another reason to punt it to the toolkit layer, sinc D-VFS
can't make those kinds of calls.

I also know that a lot of GTK and Qt code already makes use of code
where the app calls into a second main loop.  Most modal dialogs are
implemented in such a code block.  Yes, the application author
implicitly knows about it, but then so would an application author using
the glib-based D-VFS wrapper.  We could document that the synchronous
API is not to be used in libraries, unless they document that they call
the main loop.

More input from you and the Qt folks would be appreciated here.  ;-)

> 
> > Anyway, I think Sean's point is that the synchronous wrapper has to be
> > toolkit specific, while the async one doesn't particularly.  So if your
> > favourite toolkit (gtk, I assume :)) can't handle recursive calls to the
> > mainloop, just implement the synchronous wrapper using some appropriate
> > technique.
> 
> GTK+ handles recursive main loop calls just fine. It's not a toolkit
> issue.
> 
> If there is a synchronous API at all, it should be designed for non-GUI
> apps and threaded apps. A single threaded GUI app should be using only
> asynchronous APIs. (*)

KDE apparently uses a synchronous API from what I'm told.  They, at
least, have it figured out.  I know there are certain limitations they
probably had to accept while doing it - I imagine there is a lot of
modal dialog unfun during such operations, but at the very least that
dialog can respond to having a cancel button be hit and the application
can redraw on expose events.
> 
> Regards,
> 						Owen
> 
> (*) One thing that needs to be thought through carefully is what happens
>     with the synchronous API if an authentication dialog needs to be
>     displayed. This is a big problem with gnome-vfs. 

As mentioned before, the authentication dialog will *not* be handled by
the application, because it's not the application's business what your
password is for a remote share - that's between the user, his keychain,
and the D-VFS daemon.  That is also mandatory in order to do the secure
password input X extensions people have been discussing for the last
year or two, since only certain processes will be allowed to acquire the
necessary privileges.

Because the authentication dialog is handled by an external process, the
application is completely unaware that the delay in the operation is due
to waiting for user response instead of just network latency or what
have you.

The only apps that *need* to offer an authentication dialog themselves
are console apps.  There are one of three solutions to that which I can
of, being (a) just ignore them, they aren't Desktop anyhow, (b) add API
bits for registering auth hooks and ignore them if the session auth
helper is running on the same session (which hopefully means the console
app is running in an xterm), or (c) having the API allow to easily
register the app as the auth helper itself, which isn't really a whole
lot different than b and probably not nearly as safe in certain rare
scenarios.

For normal GUI apps, though, authentication will be handled fine in both
sync and async APIs.

> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
-- 
Sean Middleditch <elanthis at awesomeplay.com>