Nicolas Williams wrote: > I think that modifying svcs to filter out cronjobs is a bit much.
Maybe. I don't really understand the whole picture well enough yet. The first level is probably, as I said, showing only your own jobs. That doesn't seem all that unreasonable as an extension, because SMF doesn't yet have a concept of per-user services. (Can a non-root user currently be authorized to create new services, but only services that run as that user?) > Why do we want to store cron job info in SMF at all? Because it's got a > programmatic repository interface? That's what I think. But maybe we > need something new. > > Think, rather than svc FMRIs, how about cron FMRIs? > > Then the filtering in svcs comes free. Also, the repository for cron > FMRIs need not be the same as the regular SMF repository, heck, it > needn't even be an svc.configd instance -- it could be a local, embedded > DB private to cron itself. I don't know enough about SMF to comment here. Since I view cron jobs as being much like services - certainly as much like a service as a network listener is - I want to be able to use all of the standard "service" mechanisms to manage them - add, remove, enable, disable, status, parameters. If cron jobs use "cron:" FMRIs, why do inetd-based network listeners use "svc:" FMRIs instead of "inet:" FMRIs? >> IMHO, the right human readable representation is a GUI. > > Don't forget CLI/text-based UIs, and APIs. CLIs, yes, though I would consider them secondary as human interfaces. In particular, they can sacrifice readability for compatibility, parseability, and extensibility. APIs (other than CLIs) are by definition not intended for human consumption :-)
