(After I wrote this, I got Mike's mail forwarding Chad's messages. At this point, they don't change my thinking ... but I haven't had the time to look at the attachment he provided, to see how it amplifies what is in CVS.)
At 05:47 PM 7/5/2004 +0200, Erich Titl wrote: [...]
>(This part is, I believe, Erich's observation, just fleshed out with examples. But I think we need conversion routines only to each package's own config files, not "to *and* from" them as Erich writes.
Mhhhh... I believe in the end the _true_ files, the ones that are actually used by the LEAF box (for example /etc/network/interfaces) should have precedence over the _config_ files, because those are the files that actually get loaded. IMHO the contents of these files should be parsed and the converted to the _config_ values which could then be used in a standardized way.
>The idea is to force everything to use this config database, not just to make it another option.
This is achieved easily by letting the _config_ package just manipulate the config database. The above mentioned method just makes sure that all manual modifications get passed back to the database, e.g. If I modify the network configuration manually (bad habit) and then save etc.lrp and go home, the next poor luser that uses the configuration UI will get wrong information eeeek...
I disagree, especially with the "easily", but in general with this philosophy.
If we take this approach, then any changes made "by hand" to a non-database config file will propagate back to the database (or probably will, which is even worse than certainly will). This invites packagers to adopt procedures that break the UI. I would recommend that the system instead be set up so that every package is expected to create its separate config files during boot/init, drawing on the common database ... so we can be confident that changes made to the database always get propagated to the apps by a save-and-reboot procedure (the easiest thing to tell beginners to do).
I'm not dead set on this ... I'm happy to listen to an argument for doing it the other way ... but I don't see the case for doing it the way you propose to be so obvious that it doesn't require an explanation.
What motivates me to propose my approach is:
1. If we don't force packagers to use the config system, some of them won't, and that breaks the UI and makes things hard for naive users. (This is a perpetual battle between upstream developers and distro packagers, not something peculiar to LEAF.)
2. Having information propagate back from the app files to the database creates the risk that the configuration for one package might corrupt settings for another. Consider any of the old-days situations where users were required to enter their IP address in 2 or more places as an illustration of how this might happen. For a more current example (though one I am less certain of), what would happen to the config database if the "true" config files /etc/resolv.conf and wehatever dnscache uses contained inconsistent information? I'd bet that Shorewall could provide additional examples, simply because it has the most complex configuration system of anything that is a stock LEAF package.
3. Creating that part of the API, and getting it right, is more work, and projects ... especially ones that have languished for 18 months due to lack of developer interest ... should not require more work than they absolutely must. (At this point, you and I, and Mike, are the only people exhibiting even a passing interest in this topic ... and I haven't noticed any of us yet voluntering to complete this API.)
I'll be interested to read what you see as the strengths of doing it the other way.
I believe for the sake of a more modern UI we need a standardized API to store and retrieve config parameters. I believe also that we need the agreement of the developers involved to move towards such an API, just because they will have to maintain interface code for it.
Just to be clear ... I agree 100% with this. What I was questioning in the long discussion I deleted here is whether this *particular* API was suitable for the task, or whether it combined too much complexity with too little flexibility. After all, a file that sets a bunch of shell variables, in PARAMETER=value format, is also a "standardized API", albeit a very simple one.
I would find it helpful if someone could illustrate how the proposed API offers more genuine flexibility than a simple system of that sort, one that would be a fairly basic extension of the approach used by the old lrcfg system.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
