> This project delivers the avahi client API. Instead of delivering > the avahi daemon, which on linux and freebsd implements a mDNS > stack, we will change the avahi daemon to make calls to the > Bonjour API so that it will use the Bonjour server.
This is, IMO, poorly worded and confusing -- "we're not delivering the daemon, but instead are delivering the daemon". Erm. You're delivering the daemon, heavily modified, ripping out its guts and replacing them with a new backend. > avahi-daemon: The avahi daemon makes use of libavahi-core to > provide service registration and discovery to clients using the > DBUS interface which is an IPC wrapper around the functions > provided by avahi-core. We rename this to avahi-daemon-bridge-dsd > so that it is clear that we are not delivering the standard avahi > daemon. >From the architectural diagram, is the "DBUS protocol" the only piece of the daemon that's getting delivered? Is this a public interface? If not, then why have a long-running daemon at all? Why not just have the client library make the requests via -core (and back to bonjour)? (And if for some reason the daemon is necessary, why isn't it properly integrated with SMF?) > /etc/avahi/hosts Volatile address host mappings > /etc/avahi/services/ssh.service Volatile Static service It'd really be nice to point us at the documentation for this. I see a poorly formatted man page for this in the materials directory, but I shouldn't have to go digging for it. (That's why interface tables have a "defined in document" column.) Why are you choosing to deliver this one service? Why not others? You say it's "static"; what does that mean? Are other services dymanically generated? If so, which? And why not this one? Danek
