Nicolas Williams wrote: > I think the argument would be that if you need much more than what SMF > extended templates give you then SMF should not be your project's admin > UI.
Maybe, maybe not. As I said, a customized UI is a great thing, but expensive. Especially for CLI purposes, is it really the right answer for every service to reinvent svccfg? There's a lot to be said for system-wide consistency. I know I'll get a knee-jerk reaction from anti-Windows bigots, but it's awfully cool that you can create a configuration-setting wad for almost anything in the system, including third-party applications, in a single *.reg file and install it with about three clicks. I suspect you can use the GPO framework to install it across your enterprise in not many more clicks. > That said, I'm not opposed to external validators that svccfg(1M) > can invoke. Executables or shared objects? The latter can be used in > more contexts, but the former can be shell scripts. No strong feeling. Probably both. With a reasonable shared object API, it should be easy to implement an executable-based API. >> Look at it like you might look at a DBMS: best practice is to put >> as much validation and business logic in the schema as possible. > > Yes, but SMF is not an RDBMS (granted that it has SQLite2 under the > covers). Anything that stores data (and many things that don't) can be viewed and designed using the same principles as a DBMS. (Note, incidentally, that I didn't include "R"; I'm not sure that part is relevant here.) Consider, for instance, an API that is known to be receiving data from an unvalidated source (a user, for instance). Should that API include validation functions (perhaps embedded in the functional parts of the API), or should it rely on the application that is invoking it to know what the rules are for validation?
