Quoth Nicolas Williams on Sun, Jan 07, 2007 at 04:51:43PM -0600: > On Sat, Jan 06, 2007 at 10:23:52AM -0800, David Bustos wrote: > > Now for the long term, I initially thought another level of hirearchy > > would be required. But as we're discussing, different implementations > > don't need to share properties, so perhaps this could be solved by > > mandating that services which are subject to alternative implmentations > > (i.e., open protocols) include an implementation designator in their > > service name, like "network/dns/server/bind". Then we could allow other > > services to depend on service prefixes, like "network/dns/server", which > > would automatically depend on the instacnes of dns/server/bind. Without > > a home for "network/dns/server" properties, though, single_instance > > semantics would be impossible to preserve. > > So, how would one specify a default implementation/instance that the > generic FMRI (sans /implementation:instance) will refer to? (see below)
I don't think we have to. I think there should be a way from a GUI to say "Start serving DNS, I don't care what implementation", but it would be legitimate to say "If you're using svcadm, you have to choose an implementation". If specifying a default implementation for svcadm is a natural fit, go ahead, but I don't think it's required. > > Fixing multiple-implementations would seem to be a good opportunity to > > allow daemons to implement multiple services, too. (Not that this is > > a big problem now, but it would ensure we were logically complete.) For > > that I think we would have to allow a service to specify which other > > services it implements. That could also be used to solve the above > > problem, but it may be awkward to expose in the user interface. > > Or flip it around: allow a service to be declared an alias for another. > > Then you could mark svc:/network/dns/server:default as an alias of > > svc:/network/dns/server/<desired_implementation>:<desired_instance> > > Now, what if one daemon implements multiple seemingly unrelated > services? Contrived example: NTP and DNS; then one cannot be enabled > while the other is disabled and vice versa. My answer: "don't do that," > but I bet someone will come up with a legitimate example :/ That's the point. Trying to disable the implemented service would fail, pointing you at the implementation, and disabling that might warn you that you're taking down multiple implemented services. Of course, most such services would probably be able to have the constituent services configured to be on or off independently, which might be problematic. David
