A virtual filesystem standard

[George Staikos]

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.

> interesting problem to be solved is having a consistent
> way for all applications to use the same URI schemes to access
> fish:, dav:, camera:, and so forth.

   Sure, they're all useful.  I think that the scheme should be generic enough 
to support https for web browsers and more too.

> 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.

> >   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.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/