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
