a common VFS - a different approach

[Ken Deeter]

> 
> Advantages without switching GNOME and KDE over:
>  
>  - Can be used by applications that don't depend on GNOME and KDE,
>    and either use Qt/GTK+ directly or use their own toolkit
>    (OpenOffice)
> 
>  - Provides a sample implementation for specification we do.
>

I think another very import point in terms of open source projects is
that it would create a clear framework to integrate new technologies into.
I think some of the issues like we have where its hard to use 3rd party
drivers with xfree and 3rd party kernel modules with the kernel is
because there hasn't yet been a good separation between those components.

If we can acheive good separation here, then hopefully we can say good
bye to the situation where "this works in kde but not in gnome".. at
least with regards to vfs stuff.

You said it below, but I think this is a major point. If there are
places where the two desktops need to do the same thing, then by all
means we should have a common implementation for it.
 
> Additional advantages if we switch GNOME and KDE over:
> 
>  - Shared session state, such as passwords and certificates
>    needs shared implementation to work well.
>

I'm not sure that both desktops would want to manage this in the same
way, but I do think there is benefit in having central management.
If we make the central management scheme pluggable, then we can have both.
 
>  - We can actually have real modularity and have that work
>    for all applications on the system.
> 
>  - Interoperability *will* be better with shared implementation.
> 
>  - In the end, duplicated effort will be reduced.
> 
> Responding to some of your points in detail:
> 

> I think there is plenty of evidence that people consider VFS sorts
> of things to be interesting things to work on; look at all the
> projects that have been mentioned here recently.
>

I agree. Especially with a high profile group like freedesktop behind a
proposal, i think people who have all sorts of ideas on userland fs's would
join in, because it has a much higher percentage of acceptance.

I think most people who work on these vfs things always think to some extent
"if only all applications could use my API, then look what i could do".
This is a real opportunity for that to happen.
 
> I think you exagerate. Of course, this issue does make implementation
> harder, but certainly there are plenty of examples of successful 
> "plain C" libraries that are shared; fontconfig, libjpeg, D-BUS seems
> to be working out well.
>

I think d-bus could be an enabling factor here. It really lets you not
worry about things like ABI compatibility (in the linking sense), which
lets you be much more flexible. All you have to maintain is the message
passing protocal compatibility, which is like saying, you have to comply
with the HTTP spec. Think about all the different HTTP implementations
out there. 

 
> So, a scheme where a gnome-vfs interacts directly with the file system
> and otherwise wraps xdg-vfs is almost certain to be workable.
>

I would even say, if this such a concern, then the API for the vfs
system itself should expose local-file system specific things, instead
of relying on gnome-vfs or kio to do it. That way, the portability work
goes into one central place.

> Konqueror is going to likely be more of a challenge since it apparently
> interacts quite deeply with the SSL guts of the kio, but still,
> the issue is not realy file:// and http://, but all the other possible
> VFS backends out.
>

I think there will be always cases where the app wants to get into the guts,
and so there should be a mechanism by which this is made possible.
 
> > Since almost all gnome apps use gnome-vfs
> 
> The number of GNOME apps that support gnome-vfs (or even really use
> files) is quite small. A gnome-vfs compatible wrapper has to be
> retained, of course, but if we had a nice replacement, I don't see
> any problem in gradually moving things over.
> 
> >  and its a supported API/ABI
> > we can't really change it that much, and making it a layer over a shared
> > vfs implementation would probably require that vfs to either be so
> > similar to gnome-vfs that there would be problems with a similar KIO
> > layer, or there would be non-ignorable performance issues with it.
> 
> What evidence do you have that there would be significant performance
> issues? The network is the bottleneck in most cases.
> 
 
> This is a very manageable problem. We can tag VFS backends as specific
> to a particular desktop without any diffulty.
> 

I totally agree. Nothing says you 'have to' use a particular backend.


Cheers,
Ken

------

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