A virtual filesystem standard

[Owen Taylor]

On Sun, 2003-09-07 at 11:47, George Staikos wrote:
> On Friday 05 September 2003 11:50, you wrote:
> 
> > >   The problem, as I stated, is that the GUI code is inside the VFS for
> > > this. In fact, in some apps it's also in the app too.  It gets woven all
> > > through. SSL was just not designed with async I/O in mind originally.  It
> > > requires all kinds of settings to be shared between the app and the I/O
> > > code too.  See KHTMLPart for instance.
> >
> > I'm not sure that trying to look at what a full web browser does with
> > https:// as being "using a vfs" is going to work ... presumably the
> 
>   We do this in KDE already and it does work.  It's not easy, but it works.

It would be interesting to see details about exactly what interactions
between the web browser code and the VFS are needed.

My worry would be that adding all the necessary hooks to the VFS might:
 
 A) Make it hard to understand and use the interfaces
 B) Make it very hard to correctly implement a new file system type

Perhaps Havoc's idea of making the file system interfaces very modular -
a limited core set of capabilities with extensions - helps here.

[...]

> > If the application needs to interact with a specific protocol in a
> > complicated fashion, then that may be better thought of as a library
> > for that protocol, which might be shared with the VFS backend.
> 
>    Here is where I think things get more complicated.  For instance, if a user 
> connects with a webbrowser to https://www.example.com/ and then a word 
> processor connects to the same site, should the user be prompted twice for a 
> certificate?  Should it be considered a completely different session?  If 
> not, then it has to be serialised.  We do this in kde with a kded module for 
> ssl serialisation, session ID handling, etc.
> 
> > GUI interactions do arise in simpler cases:
> >
> >  - Prompt for a password
> >  - Put up one of those semi-useless dialogs warning about certificate
> >    probles, etc.
> >
> > But these type of interactions seem to be well solved by a simple
> > protocol using D-BUS to let the VFS backend talk to a "dialog server".
> 
>   Yes, as we do in KDE with DCOP presently.  Again, it's not "simple", but 
> it's doable (as I said).  I would rather hope that a cleaner solution could 
> be found for a common backend.  This is my concern.

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.

> > >   Also we have the need for kssld to synchronize sessions and the
> > > certificate database across various io slaves.  This will be quite a
> > > challenge to implement portably.  This is what I was referring to as the
> > > OpenLDAP approach.  It's really quite aweful, and they're only dealing
> > > with a single LDAP connection at a time, unlike HTTP.
> > >
> > >    It's doable of course, but it's quite complicated to get right in
> > > comparison to the rest.
> >
> > I'm not at all familiar with the issues here, but in general, I'd
> > think an out-of-process setup makes things easier, rather than harder.
> 
>   Yes it often does.  Some of the libraries out there (openssl, openldap, ...) 
> don't seem to consider the concept of doing things in ways outher than 
> letting the library do all of the work inline.  It makes life rather 
> challenging.
> 
> > After all, if I browse to an SSL DAV URI using my file manager, then
> > drag-and-drop the URI into my word processor, then the file manager and
> > the word processor need a synchronized view of certificates,
> > authentication, and so forth.
> 
>   Yes, which requires a daemon, etc, as stated above.  And it requires a new 
> idea of what a "session" is.  It requires lots of complicated IPC and 
> callbacks for user interaction, etc.
> 
>    Already KIO wasn't really designed with many of these issues in mind.  We 
> have hacks for many of these things instead.

What would be of extrodinary value, I think, would be a writeup of 

 - What works well with KIO
 - What doesn't work / requires hacks
 - How it could have been done better

I can try to get someone familiar with gnome-vfs (maybe Alex Larsson) to
do the same for that.

Regards,
						Owen