At 10:24 PM 7/5/2004 +0200, Erich Titl wrote: [...]
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.)
Force.... such a strong word. It will be hard to force anyone to change his API when his product is distributed a zillion times, successful and he's moved on to other chores. Of course you are right, but this is not the ideal world. I would prefer the _invite_ method :-)
I was not sufficiently clear here, I'm afraid. There is no way to force actual developers of applications to do anything. But we can insist that anything packaged for LEAF conform to LEAF packaging standards, just as other, larger distros do. Debian, for example, limits official .deb packages (there are unofficial Debian repositories, too) to ones that conform to Debian packaging guidelines and that are maintained by a registered Debian maintainer.
An example of this, one familiar to LEAF developers, is Shorewall. Tom himself distrbutes a .tgz, a .rpm. and a .lrp version of Shorewall. A Debian maintainer other than Tom repackages Shorewall as a .deb (Tom links to it on the Shorewall page).
I don't know the mechanism, but the various .rpm-based distros must do something similar, at least for the packages they make part of the distros.
That is why I spoke of forcing *packagers* (not developers) to use the system. Sorry if my prior lack of precision her eclouded things up.
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.
Good point, something that bothered me a long time.
Actually, a couple of comments Chad made today are relevant here. I don't understand how the leaf-tools config system can enforce either entry locking or uniqueness of variable names. If any script can write to the database, then (potentially) any package script can change global settings. And there might also be race conditions and deadlocks. All of this is not actually awful in an embedded-systems setting like LEAF ... it's not even unusual ... but embedded systems don't usually support drop-in packages either. Probably Chad and the others implemented some mechanisms to handle this stuff, but I've missed what they are.
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.
Your analysis is convincing, especially as it covers the most important part of getting the system configured the way the user wants it.
My suggestion to allow the inverse way was wrong in the way it was formulated. I would actually love if the UI showed the _actual_ state of the system. regardless of the config files, because the end user will typically also use such tools to check the actual system status.
If this is consistent with the system status at load of the UI we'd have a good starting point.
Yes, this is a tough one. For any UI to work, LEAF has to insist on *some* sort of cooperation from packagers. Using the config database exclusively is my current candidate "something".
Another is that a package always include a script that will, on demand, read all its config variables and report them in some standard form (hey, how about the database format?), and another one that will accept back that same list of variables in a standard form and update the config files. This is close to what you were suggesting.
There are probably other ways to do it too.
But if we don't require *something* of packagers (not of upstream developers; remember the distinction), then no config system will ever be able to handle a complete range of possible drop-in packages.
The only hope of making something like this work is to remember that, in the end, LEAF may be a pretty complex router, but it is a pretty simple Linux system. It will never need to have thousands of packages available, probably not even hundreds.
Whenever a change is confirmed in the UI this state should be written to the config database _and_ the system which would keep us in a consistent state. This would, of course, require quite a sophisticated control mechanism, e.g. when the user changes an IP address, subsystems like shorewall and ipsec would probably have to be reconfigured and restarted.
Right. I think that's what the "trig" mechanism in the leaf-tools package is there for ... to facilitate restarting or re-HUP'ing subsystems whenever a database change relevant to them is committed. (Even, conceivably, forcing a reboot, though I hope that use would be rare.)
After writing this, I saw Chad's message about trig, pretty much confirming this understanding, but indicating it is even more flexible than I inferred. Moreover, his comments suggest that there is, in the shadows behind the code, a mental model of how a package would interact with the database. It may not be a complete model at this stage, but there is probably more to it than is plain from the code itself. Some discussion of this might be profitable.
-------------------------------------------------------
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
