On Mon, 2006-04-03 at 02:48 -0400, Horst von Brand wrote: > David Zeuthen <david@xxxxxxxx> wrote: > my view is that if we solve > > it for desktop then the server bits will pan out mostly by itself. > > No, the problem spaces are different. Doesn't have to be. > Bingo! I.e., configuration /is/ needed... Certainly. > So you advocate not configuring the web server via files, but remotely via > LDAP? How is that different from "configuration files"? It's different insofar that since you already serve configuration from the LDAP server it's next-to-trivial to use the same mechanism to actually change the configuration. Hence, it's a lot easier to write a single configuration UI (or whatever) that all distros can use. In particular we don't need a all-generic system like Elektra here. And you really want your web server process (e.g. httpd) to know that it reads configuration from the remote end to fix all the corner cases in a nice way. > In any case, this is system-wide, just that your system is larger than one > box. Terminology. That's what I call site-wide. > Great. But that does mean that someone, somewhere has to tweak the > configuration (files) with all those desktop settings that the machine gets > over the net. Just add an LDAP backend to gconf and you can control all desktop policy from a central repository. Also look at other approaches for this e.g. Sabayon. Like it or not but gconf is pretty well designed and the "implementation detail" of reading from /etc/gconf or LDAP is just that: an implementation detail. Hell, once you add LDAP you can go on and refine our UI tools to edit default settings and lock-down from the standard dialogs like for instance the power management dialog http://www.gnome.org/projects/gnome-power-manager/gpp.html Maybe this tool would look like this http://people.freedesktop.org/~david/davidz-evil-admin-console.png (historical note: this mock was done about a year ago) > Plus I'd bet the number of single-machine setups vastly > outnumber the multi-client setting you describe, and will for a long time > to come. By pushing the problem into the site-wide system administrations > hands you have solved nothing. Site-wide implies something like LDAP to read configuration. Hence, configuration utilities (should they be desirable) can use the same protocol to write settings. > > - Things like smb.conf is really not interesting for the desktop > > case as it's the wrong solution to the problem of sharing files and > > using files other systems wants to share. The right answer here is > > obviously things like Nautilus and gnome-user-share and other things > > that run in your session and is easy to configure. > > Destop has no business in deciding what system-wide resources to share. Of course it has. Do you expect admins migrating from Windows or Mac OS X to sit down and learn the horror of all the configuration files? Of course not. My stance is that you want a system where this is configurable from the UI. Even if you want share system wide stuff, maybe this just requires the user to auth in order to allow this. > > > - X.org having a configuration is completely broken too; obviously > > the X.org server should be able to configure itself (and it can but > > X.org itself has bugs so it doesn't always work) and it should offer > > a D-BUS interface for reconfiguration so some per-session piece of > > software can program it with the users setting when your session > > starts. > > Pray tell, where would the user settings come from? Not from a > configuration file?! For GNOME it would of course come from gconf. > I'm not so sure. The display is a system resource. No, it's per user. Do not pass start. Do not collect $200. > > I don't have a good answer to KDE and GNOME sharing configuration; I > > personally think that as this point it's impossible to get developers > > of both camp to agree on a scheme for even simple things like desktop > > backgrounds and HTTP proxies. And should the day come when gconf > > depends on KConfig, vice versa, or when there is D-Conf I'm sure this > > will get solved by itself. It sure as hell doesn't need Elektra for > > this. > > That is the crux of the matter: Glorious schemes for world domination "if > only everybody will agree on the same configuration file syntax" are thrown > around here, but the ones in charge of adopting said syntax have > historically shown very, very little desire to agree on a syntax. And > (assuming people aren't completely irrational), the very existence of the > wildly differing syntaxes tells me there are different needs behind them. Yes, that's true, however I don't think it's totally important that GNOME and KDE share the setting for e.g. wallpaper. Mostly, I just stick to GNOME apps anyway. But I'm sure someday there will be some desktop settings that GNOME and KDE will share. > So your idea is getting rid of configuration files and push everything into > LDAP? What if the LDAP server is down? And you need to cache stuff for disconnect operation e.g. laptops. I think Microsoft showed this was possible with AD. > Who says LDAP is the right framework, i.e., is rich enough for the needs? > Who says the result won't be just shoveling the garbage into another opaque > junkyard? I'm not saying this is easy. But I am saying we need to be a lot more ambitious than e.g. Elektra. I agree this is a very difficult problem space to navigate in, especially because of the very bazaar nature of open source. It's definitely fixable if we get the right architecture hashed out to begin with. David -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
