A virtual filesystem standard

[Ken Deeter]

> What would you think of as being a cleaner solution? Having the VFS
> backend process/processes directly connect to the display doesn't seem
> very clean to me. Having the application having to handle interactions
> with the user doesn't seem all that clean to me, and certainly not 
> convenient for the programmer.
> 

I think having the backend connect to the display is pretty bad, as
you may get into questions like, well what GUI toolkit does it use?
where is the display? To make it desktop agnostic, the user interaction
has to be decoupled from the backend doing all the work.

Would it be possible to do something like pass in some kind of reference
to an 'authentication adapter' to the vfs backend. Each backend would
define some kind of interface (i'm not too knowledgable about D-BUS but
if its like any other object model then I'm guessing it can define
interfaces) that it requires its authentication handler to implement, so
we can handle special cases like ssl or whatever might come up in the
future. Also, the same authentication adapter running in some daemon
could be passed into multiple instances of a backend, and things like
sharing ssl certificates can be supported w/o too extra infrastructure.
If the authentication adapters can be out of process (out of the vfs
back end process) then it really enables flexibity in terms of various
authentication semantics like 'sessions'.

This would let vfs backend developers not worry about the kind of GUI
things that they shouldn't have to. It lets each desktop potentially
roll its own set of authentication adapters that are based on each
desktop's design philosophy and also desired functionality.

What might also be interesting is if the currently running desktop could
register at the start of the vfsd (or at any time i guess) a set of default
adapters so that things like command line programs could just say 'i want
this file, use the default registered authentication adapter' and the right
desktop-dependent GUI will pop up automatically. I.e. so doing a vfs-enabled
cp in the terminal will bring up the right gnome GUI in gnome and the right
KDE gui in KDE.

I suppose if there were ever to be commercial back ends, then they might
want to roll their own authentication adapters, so there should probably
be a way for the backend itself to provide its own adapter. Since the
interface would still be defined, it would be possible for a desktop to
at a later point implement that interface and provide an integrated
solution instead of the back-end provided solution. To make add-on back-ends
always useable, we could say that they must always provide their own default
authentication adapter, but then that probably means every backend will
depend on some GUI lib and i'm not sure thats ideal.

Also, if there is a case where an application needs some kind of special
interaction, or if the authentication needs to be integrated into the GUI
of an app, then the app itself could pass its own authentication adapter
when making vfs calls, overriding the default.

The other related idea would be to define some kind of data model for
authentication data, and have a standard interface in which the backend
could pass an object adhering to this model to a GUI-integrated server
who understood the model and could show the appropriate GUI for it. This
however, would probably force the backend to define various semantics,
and the model will likely break down eventually, requiring some kind of
versioning and all kinds of confusion.

I don't know of all the different kinds of authentication mechanisms out
there so I wouldn't have any idea where to begin making such a model,
cept maybe username and password.

Dunno if its the best solution but i think it address all the concerns
that have come up on this thread so far..



------

 +----------------------------------------------+
(  Ken Deeter (Kentarou SHINOHARA)             (
 )                                              )
(  "If only God were alive to see this.. "     (
 )                             -Homer Simpson   )
+----------------------------------------------+