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) > 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 :/ Nico --
