Hello Jonathan Yu <jonathan.i...@gmail.com> writes: > I see these two tools as complementary, rather than competing, > technologies. You can use the data parsed via Augeas (which to me > seems like more of a lexer/tokenizer part, kind of like what yacc/lex > do) to get data from the file using a grammar.
Indeed. From a user's point of view, the big advantages of Augeas are: - provides a unified API to edit files in /etc (whatever their syntax) - preserve structure and comments of original files - available in several languages (Ruby, Perl, Python, C ...) The main drawbacks: - Only augtool user interface - Not much validation. - Error messages can be cryptic. > Then you need some code, which is provided easily through > Config::Model, to actually validate what you've got, make sure it all > makes sense (for example if you're trying to parse XHTML, then to make > sure certain elements like <p> are inside <html>). Compared to Augeas, Config::Model provides: - stronger validation that can take into account more than one parameter (1) - integrated help - filter parameter according to user skills - configuration upgrade capability (2) - more user interfaces (Perl/Tk, Curses ...) - understandable user message On the drawback side: - Only Perl API - Comments and structure of original file is lost The latter point can be avoided if Config::Model::Backend::Augeas is used. You can then get the best of both world. But this has a cost: you need to have both Augeas lens and Config::Model model. See libconfig-model-openshh for example. > I suppose you could also write such code yourself, but then you'd need > to write both accessors and mutators to do that sort of validation, > which I imagine is something Config::Model does on your behalf. Yes. > Finally, it should be noted that Dominique is the maintainer of both > modules, so he wouldn't have packaged them both (and went through all > the trouble of writing Config::Model in the first place) if there > wasn't a good reason :-) Using Augeas will avoid writing writer and parser for some configuration files. Only the models will be left to write. > But I'll leave it to him to correct my understanding here. You're doing fine. Thanks :-) All the best (1) For instance, in xorg.conf it could validate that a Monitor mode is choosen from the list of default Modes or from the list of Modes declated in the same file. (2) Models can contain rules to be able to migrate deprecated configuration paremeters to newer parameters. For instance, old sshd_config parameter 'KeepAlive' could be migrated to new 'TCPKeepAlive' during package upgrade. -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org