Alan Maguire wrote: > hi Rishi > >> Open question: Considering the above future work to include this support >> in the master SMF restarter and new properties introduced to customize >> the service advertisement is it better to create the 'advertised' >> property under a new property group 'mdns' that is not specific to a >> restarter? > > i wonder if a more "delegated restarter-agonstic" approach would be easier, > i.e. have a dedicated mdns property group as you suggest. the advantage of > this > would be that adding advertisement to a service could simply create this > property > group for the delegated restarter to pick up (if not already there), i.e. > > # boujouradm -a telnet:default > > would add the mdns property group to the telnet:default instance (with a > default > name matching the service name) and restart it. the hooks in the inetd > restarter would then pick this up and communicate with the > mDNS daemon. > > i think in most cases the service name matches the /etc/inet/services > entry for port lookup, but exceptions could be handled by explicitly adding > the mdns property group. the advantage of this approach would be > that only the SMF manifests of services which have names that do not match > their entry in /etc/inet/services would have to be updated with an mdns > property > group. > > each delegated restarter would still need hooks to communicate with the > mdns daemon to announce that the service is online/offline/in maintenance > state, but these hooks would not be so restarter-specific (i.e. they'd all > query > the same mdns/advertised property, they'd all do nothing if there was > no mdns property group etc). > > this approach might make life easier when adding non-inetd services, > maybe i'm missing something though? thanks! >
Thanks Alan for the feedback. I agree that this approach would certainly make it easier in extending "mDNS" support to other SMF restarters in future. Thanks, Rishi
