A common VFS and a Common conf-system [Part II]
elanthis at awesomeplay.com
Tue Mar 8 22:24:27 EET 2005
On Tue, 2005-03-08 at 21:01 +0100, nf2 wrote:
> Sean Middleditch wrote:
> >On Tue, 2005-03-08 at 11:37 -0500, gtg990h at mail.gatech.edu wrote:
> >>other applications in which 'desktop' and 'CLI' apps have to work together.
> >>We're talking about UNIX desktops here --- CLI apps won't just go away, and its
> >>useful to the user to allow them to work together.
> >Then they will need to be ported just like the desktop apps. I'm rather
> >looking forward to getting some CLI apps using D-VFS, such as Vim.
> I agree with that - DVFS should also work in a GUI-less environment -
> but there might be a problem with secure authentication. If
> authentication callbacks are directed to the client application like in
> Gnome-VFS it would be easy: The CLI client application could just prompt
> the user for the password. But if you want a secure solution with a
> "trusted helper process to do all user interaction" (I think KIO does it
> that way) this might be more complicated...
This was something I was thinking about, actually. It is a problem when
you're not running in an xterm or whatnot. My current thinking is that
since the authenticator will not be the daemon itself, but a D-BUS
service, that it would be possible for an application to register itself
as the authentication helper. In a console environment, this would just
work. When the same app is run in an xterm, since there would already
be a registered authentication helper (or should be), the app would not
become the auth helper and the normal desktop utility would keep
That might be kinda flaky when starting up a very lite weight X session
and then running a console app in an xterm and then starting up some
other D-VFS using apps, though.
It would also be possible to just have an API in D-VFS for adding auth
callbacks, and then have the daemon refuse to use them if an
authentication helper is already running on the D-BUS service. That
makes more sense to me, personally, but there might be some downsides to
it that I haven't thought of. Anyone?
> xdg mailing list
> xdg at lists.freedesktop.org
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg