On Tue, May 27, 2008 at 04:40:14PM -0700, Jordan Brown wrote: > Nicolas Williams wrote: > >I don't agree. A better crontab UI doesn't really need property groups, > >for example, so to have those visible by dint of re-using SMF as-is > >seems lame. > > No? How do you configure parameters for your cron job? Shouldn't the > log retention policy be controlled through SMF properties? Tweaking > command line arguments is so very 20th Century.
"property groups not needed" != "properties not needed" The point is that I don't see a need for grouping properties of a cron job in more than one property group, which means there's no need to expose property groups to the user in the UIs, nor to the developer in the APIs. (This same point has come up in the design of the name services next-gen config project, project Duckwater.) > The reason that I don't think that the repository can be in $HOME is > that (a) there's got to be *something* in the root that tells SMF to run > something for this user, because we can't very well have tens of > thousands of systems each scanning tens of thousands of users' home > directories looking for something to do, and (b) I want to run some > services on one machine and other services on another machine, so the > systems better have separate repositories. User services could either be associated with sessions (though, of course, GNOME in a way already supports this with panel applets, for example), in which case the session manager launches the user's SMF daemons; or not, in which case there should be a system service that launches specified users' SMF daemons (and the repositories can live anywhere the sysadmin wants them to). > Look at it another way: current crontab is per-user / per-system. > Maintaining that status quo is my goal. (And note that crontabs are in > /var, not in $HOME.) Something oriented around managing desktop > sessions might be very interesting, but seems completely separate, scope > creep of the finest kind. Creeping featurism, blah, blah, blah. But think outside the box. If you'll re-use SMF infrastructure then what happens if the way you do it is such that you have not just a single repository per-host, but also per-user (per-user at host, whatever) repositories? Why, then you can have per-user at host, per-user at domain, per-session, ... repositories and all depends on what system conponent launches what per-user* repositories when. So you don't have to provide a full range of functionality, but if you pick the right _component_ to re-use then you get to enable much more functionality than you might otherwise have thought possible. So, should that component be SMF _services_ or _repositories_? Either way you might get what you want, but does one way offer significant advantages over the other? Nico --
