A common VFS and a Common conf-system [Part II]

[Philip Van Hoof]

On Tue, 2005-03-01 at 19:20 -0500, Sean Middleditch wrote:

> 
> Getting people to migrate from gnome-vfs will be easy, since the number
> of apps that use it are pretty small - it sucks incredibly hard, and
> even most core GNOME apps don't support it, or don't support it
> completely.  Broken by design, like I said.  

I'm not disagreeing with that. But the main reason why a lot GNOME apps
don't use gnome-vfs is because a lot such application developers find it
cool to only depend on Gtk+. Whereas gnome-vfs is yet another "GNOME"
dependency added to the chain. It looks like word "GNOME" is evil in the
minds of a lot Gtk+ application developers these days.

A 100% pure Glib/Gdk+/Gtk+ application is perfectly and easily portable
across many platforms including Microsoft Windows. A GNOME application
isn't. These days it's cool to be portable.

But don't take the fact that not many applications are using gnome-vfs
to light. There's lots of important and difficult applications that
depend heavily on gnome-vfs. Applications Like Evolution (partially
integrated with gnome-vfs), Nautilus (fully integrated and deeply
connected with it). Changing their vfs-layer is probably a larger
project than creating a new vfs-layer/subsystem. Don't underestimate it.

And it's the projects changing the vfs of large applications like
Nautilus, Konqueror and Evolution who'll make any new such vfs a success
or a failure.

> That's a ways off, though - D-VFS actually has to be written first.  ;-)

Yes. Lets start doing our analysis. I think some discussion with the
maintainers of the large applications (I've already mentioned a few) who
are potential or existing users of a vfs-layer should be setup a.s.a.p.

For example on IRC. Or on meetings like Guadec this year. Although I
find that date a little late. Some people might already have started
coding on this thing by then. Well .. I hope.

After that analysis we should write a first API-proposal and reanalyse
it: For example by imagining WE are assigned to migrate a specific part
of such a large application to the new vfs-subsystem. And then check
what problems we're having, and addressing those problems long before we
start throwing a new vfs-layer to the core desktop application
developers.

I mentioned one issue that immediately came into my mind: The one about
the fact that most Gtk+ applications are thread-aware, not thread-safe.
Simply because Gtk+ isn't thread-safe but only thread-aware. I can
assure you there will be thousands more such issue's and problems.

Any single such problem can cause a maintainer of a larger core desktop
application to decide not to start using this new vfs-layer. Which will
in turn infect many other maintainers. Which will void any effort going
into building and designing this vfs. Let's all agree thats not what we
want, right? We'll need a great acceptance from the most difficult kind
of species on this earth: developers. Not "just" acceptance.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org