Date: Sat, 25 Apr 1998 02:35:16 -0600 (MDT) From: allen campbell <allenc@verinet.com> To: config@FreeBSD.ORG Subject: Re: Config Databases Message-ID: <199804250835.CAA19174@const.> In-Reply-To: <4474.893404047@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > problem: how is the user supposed to know he made a mistake ? You ca > > He'll know it pretty conclusively, I think, when the change he just > made mysteriously has no effect whatsoever and doesn't show up in the > file. :) The operative word there is 'mysteriously'. Jordan, this is dubious. First, as a result of a simple typo you get to lose your work (assuming you are not using merely a working copy.) Second, you are given no clue as to why. Lets call it Pavlovfs :) An analogy might be to use a compiler that reverts your source back to its pre-mod state and reports nothing. Are you suggesting this as a short term condition to speed development, implying something better would eventually be supported? > > In the first suggestion (silently bouncing) means there's not even > > _trace_ of the mods, right ? Hmmm.. > > Right. I'm not saying that this behavior is ideal, far from it, I'm > simply saying that this is the lowest-impact approach and will require > the least programming headache. In the main, the parser code already exists inside the programs which read the existing configuration files. Where one of these modules detects an error, it's not difficult to elaborate a bit and cause a message to be output. If a simple method to accumulate and output these messages is provided, I don't think its asking much to support it. BTW, there is no reason to delay an implementation as a result of adopting a particular feedback method. If the early versions of any particular parser contains no error reporting at all, so be it. > as an intellectual exercise, of course, and there's no intention of > actually implementing it in which case by all means let's discuss all > the errors one might pass back on close() in hopes that the > application will even check the return value. :-) > > Succeeding silently and using secret knowledge of the file format to > tack in comments also strikes me as a cute but ultimately untenable > workaround, so I really do vote for the simpler approach. If the portal file system is responsible for generating these files directly from the database, it's hard to argue that it shouldn't have complete knowledge of the file format. The 'cute' point is taken. Automatically annotating a file with comments is hard to generalize and could prove impractical given very large data sets. Please consider another alternative; Configfs could redirect whatever error messages are generated by the parser to a portal file which parallels the target file. A mock session... $cd /etc $vi syslog.conf [ .. A mistake is made in a facility name .. ] $cat syslog.conf.err * * syslog.conf.err * * Error on line 4. * Invalid facility. * * Errors detected in syslog.conf. * See syslog.conf(5) for help. * $vi syslog.conf [ .. The mistake is corrected .. ] $cat *.err cat: *.err: No such file or directory $ No comment hacks here and we use the blessings of the portal file system to report the errors. Not checking the corresponding *.err file is pilot error. The *.err file persists until the problem is resolved. Again, comprehensive error detection and reporting does not need to be a prerequisite to actual progress. Just that a solid method exists within configfs is enough. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804250835.CAA19174>