>We *will* resolve the svccfg import bug. What's left is to decide >for dns/server: > >- are the implementation (of multiple instances of our dns/server) and > upgrade challenges which result from moving everything to the instance > surmountable? > > Probably, but it's ugly. That's what 6509773 should resolve. > Whether it's the right strategy depends on the time-frame for a > svccfg import fix plus a resolution to the next question.
Would it make sense to implement 6509773 for the short term and then work on a better solution in the long term, and basically take a two-pronged strategy? >- Is moving everything to the instance for multi-instance > multi-implementation services the right long-term choice, or > is some sharing appropriate? I would very much think that some sharing would be appropriate. Actually, it it almost certain to fall into two categories: a) service instances which provide the same service, but other than that, don't have anything in common, including properties, methods, or property groups b) service instances that have some overlap, and where that overlap can and should reside at the service rather than the instance level. >c) > > Does the convenience of method and dependency sharing for the common >case > (the dns/server we ship) justify forcing alternative implementations > to explicitly override the methods at the alternative implementation's > instance? I feel that it does not. Convenience of method and dependency sharing is of no use if it does not apply for the task at hand, which would be integrating one's own implemenation into the OS, into the "slot" designed for it (and there really isn't any better of a place to put an alternative DNS service instance than in /network/dns/server!) Now, I recognize that this very well might not apply for some other scenarios. My proposal is to handle these on a case-by-case basis, at least until a better long term solution is available, and excersise reasonable judgement where appropriate. For example, we all know right off the bat that SSH will almost certainly cover both scenarios, where someone would want another instance of Sun's SSH on a different port, or even implement their own instance, for example SSH Communications's SSH or OpenSSH and perhaps even several of those on different ports! So it should be possible to a) run Sun's SSH instance on a default port (:default) b) run Sun's SSH instance on an alternate port concurrently (:sunwalt449) c) run SSH Communication's on an alternate or default port concurrently (:ssh, obviously Sun's SSH would have to be in a "disabled" state if this instance ran on a default port) d) run OpenSSH on an alternate or default port, concurrently. So whatever the implementation is, it ought to be able to cover all those cases, for all of the init.d-like services currently in existence (and perhaps even inetd ones). _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
