A common VFS and a Common conf-system (Was: namespacing)

[Philip Van Hoof]

On Mon, 2005-02-28 at 12:42 -0500, Sean Middleditch wrote:
> On Mon, 2005-02-28 at 17:59 +0100, Philip Van Hoof wrote:
> >So what to use then? "fdo"? "f"? 

> Something should probably be chosen on a per-library basis.  For a
> Common VFS, for example, I'd personally just use vfs_ (and VFS_ for
> constants).  The actual style might be useful to define, such that the
> complete stack of APIs officially "sanctioned" by FDo have a similar
> style, but I don't think it's really *that* important.

And now you mention it. Is there efforts going on to actually have such
a common filesystem abstraction layer and a common configuration system?

I've read the thread about gkio but am not (yet) convinced this is how
we should solve the problem.

For the vfs I'd say we extract shared/shareable technologies and best
practises from both kio and gnome-vfs and put those in a new library
thats also usable on it's own. Then we adjust both libraries to use the
shared functionality from that library.

For the configuration system I'd redo a gconf-style configuration system
that's using DBUS. Then adapt the GConf caller library (the API which
implements the functions itself, not the daemon) to start using that
newer daemon. And create a Qt/KDE library-version or adapt whats being
used for configuration on KDE at this moment.

I've read that lots of this idea/these ideas is/are already planned

	 http://www.gnome.org/projects/gconf/plans.html

But to get gconf more accepted by the non-GNOME users, I'd really rename
all of it to xdgconf or xdconf or just conf. Hence my first question
about namespacing.

My personal opinion is that freedesktop.org only really really succeeded
in their goals (or can succeed) once they got those two crucial desktop
component conflicts resolved for both the gnome and kde desktop. Both
worlds should really be sharing this type of libraries.

And my opinion is that even the xserver should be reading it's
now-xorg.conf-structures from that registry. And it should also listen
on events like "when the configuration-key which holds the
resolution-information is changed". 

In fact. In the end it should be that Qt/KDE and Gtk+/GNOME was a
developer-only choice. NOT a user-choice. But we can't achieve that by
going further and further away from each other! The fdo initiative is a
great start. 

The Linux Kernel developers overcome redundant systems all the times.
LVM -> LVM2/Device Mapper. /proc/non_pid_stuff -> /sysfs/. or the whole
story about kobjects. The build-system for modules. Why can't the
desktop developers learn working together? How are we suppose to show
the world that we, as a bunch of free software developers, have the goal
of bringing (free) software closer to people, if __we__ can't get closer
to each others development efforts?

We really have to do something about this. And I do mean now. Today. Not
tomorrow. 

Whats the viewpoints of the developers of libraries/technologies like
gnome-vfs, kio, kconfig and gconf on this?


If any serious effort starts that will solve issues like these. I'd be
glad to be "extra brains" for your project.


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