FD.o subsystems (was:Re: some changes for (slightly) faster boot)

[Havoc Pennington]

On Tue, 2005-01-04 at 20:23 -0800, Rahul Sundaram wrote:
> I believe the current one is written by you. In that
> case you are probably the most suitable person to do
> it if you have the time..

Sure, but I don't. ;-) Someone at Red Hat might eventually, but it just
depends on the priority queue.

> > D-BUS is moving along nicely, which would give you
> > the basic building
> > block.
> 
> I dont see how a more universal registry of settings
> is going to use an IPC mechanism as a building block.
> Would you please care to expand on that. is this
> future plan documented somewhere just like the gconf
> link :-).

It's at the gconf link, gconf is IPC-based.

There are two basic parts to config system of the future in my view, one
is a client library that manages schemas on the client side (loading
fallbacks from them, locating the schema for a particular setting).
The other is a daemon that provides the current settings, but has
nothing to do with schemas. This removes the major reasons that gconfd
is complicated internally and the major reasons that admins and
programmers get confused about it. Also gets rid of the RPM %post
scriptlets that run gconftool. In short we make schemas something that
are dealt with transparently inside the prefs library by not having the
idea of "installing" them.

> > The "future gconf" described at the link I posted
> > *should* be a fair bit
> > easier to implement than current gconf is, and less
> > code in the end.
> 
> I guess that means you expect a complete rewrite. 

Maybe eventually but it's not strictly required in the short term; you
could recycle a bunch of code from current gconf. In fact you may want
to recycle the file format parsers so people don't lose their settings. 
Though the file format sucks, it most likely isn't worth fixing since
nobody reads/writes it directly anyhow.

> believe a newer version of KDE and gnome which breaks
> binary compatibility is the crucial point to push thru
> fundamental sub systems like dbus and gstreamer for
> example. I would love to see a universal gconf like
> system being adopted by next major versions of the
> DE's

You don't have to break ABI really since you can add a new ABI and keep
but deprecate the old one.

I'm not really optimistic that a config system spanning GNOME/KDE can be
done; that's why I phrase the goal as writing a "shareable" config
system. The reason is that KConfig and GConf are just a little bit too
different. So to me it will be hard to get up-front agreement on what
the system should be like, the only real possibility is to write a
system that everyone could use in principle, and then let it compete de
facto.

> Also useful would be a discussion to create a fd.o
> system as kparts/bonobo replacement. would dbus fit
> the basic needs here?

You have to separate three things:
 - IPC
 - component system
 - widget/control embedding

A problem with Bonobo was trying to do all three of those at once and
being fuzzy about the use cases for each one and how the three things
are different.

D-BUS is IPC only. Component systems look like they are going away in
favor of plugin systems (as in Eclipse) and sufficiently powerful object
systems (as in C#). You really want to be able to use multiple IPC
systems (SOAP, D-BUS, XML-RPC, or whatever) depending on your needs, so
you want to keep that orthogonal to the object/plugin system.

Widget embedding is something we could implement over any IPC system,
really the hard parts have nothing to do with the IPC system and
everything to do with what you send over it. i.e. reconciling the
semantics of Qt vs. GTK+ and what they expect from an embedded control.
The more capabilities you have (such as menu merge) the more potential
for semantic mismatch.

Havoc