On Tue, May 27, 2008 at 01:17:30PM -0700, Jordan Brown wrote: > Nicolas Williams wrote: > >On Tue, May 27, 2008 at 12:48:22PM -0700, Jordan Brown wrote: > >>Nicolas Williams wrote: > >>>It's probably not that hard to add such a thing. I can see cron having > >>>its own svc.configd repository (with mods for doing authorization > >>>somewhat differently than SMF), for example, and a simplified API > >>>layered atop libscf; plus svcs/svccfg/svcprop-like UIs, plus Visual > >>>Panels support. > >>That sounds like a whole Goodyear store worth of reinvented wheels... > > > >How so when you'd be re-using large chunks of the existing SMF > >framework? > > It looks like you're reinventing all of the SMF UIs, to begin with.
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. > >>I don't deny some desire for specialist UIs, just as you presumably want > >>[...] > > > >^desire^need^ > > OK, but the same applies to inetd. I don't agree. > >Start with a new restarter, and new property group type so as to provide > >different authorization semantics than SMF provides today. > > It doesn't seem like you should need any new properties, at least not > ones that users should have to look at. If I (a random user) say to > create a new service, it needs to be tied to me through mechanisms that > I cannot affect. See above. But that new property group type would be an implementation detail used to select authorization semantics that are appropriate for cron jobs. > >The FMRI type issue is somewhat orthogonal, but I agree that cron jobs > >and user services shouldn't be listed by svcs(1). Yet I don't think > >svcs should have to be modified to filter certain FMRI prefixes by > >default -- filtering by FMRI type seems much more appropriate, plus it > >seems more natural/less confusing as a UI. > > I think user is orthogonal to FMRI type, that a per-user inetd service > FMRI should have the same form as a system-wide one. For user services the key difference is repository and running snapshot locations. > It *does* seem like maybe the FMRI type should be tied to the restarter, > but that boat has sailed: inetd based services are "svc:". Maybe, but new restarters can differ so much from existing ones as to justify it. > Syntactically, perhaps you just add a "user@" somewhere in the FMRI, > just as you can in http: and ftp: URLs. We already have a way of naming the repository/scope. > >But I'd argue that user services too need their own FMRI type, and > >certainly their own repository (stored in your home directory by > >default), since you'd probably want them to follow you, rather than your > >choice of system to login to. > > No, it's pretty clear to me that per-user services must be tied to a > particular machine. I want them to run all the time - that is, after > all, why I'm running them as a service instead of as part of my desktop > session - and if I'm not logged in, which of the tens of thousands of > machines that I could log in on should they run on? It may be desirable to tie some per-user services to a given host, but not others. That former says little about what repository they should reside in, but the latter does. > Stuff tied to my desktop session, yes, but see the other fork of this > thread. Again, if you can tie running instances of user services to a session, then you'll probably want a per-session running snapshot of the per-user repository. Nico --
