On Wed, Aug 22, 2007 at 10:23:41AM +0100, Padraig O'Briain wrote: > The architectural diagram is at http://avahi.org/download/overview.png.
Yes, I saw that. I just didn't see any reason to ship the daemon, given that its only clients appear to be part of avahi (I think; I may be misreading the diagram). The diagram also doesn't take into account the changes you're making to avahi to use bonjour instead of the mdns stack in avahi (i.e., it's not the architectural diagram for your project, but a different, somewhat related project). Also, all architecturally-relevant materials need to be part of the case materials, and not somewhere out in the wild blue yonder. > I saw no reason to remove the static services support so that should work > on Solaris in the same way as other platforms. The static services which > are provided are those in the standard avahi. > > The reason for using the daemon is so that applications which use the DBUS > calls rather than the avahi client calls can work on Solaris. I do not know > of any such applications currently but there seemed no point in making > trouble for ourselves in the future. > > The daemon is integrated with SMF in that an SMF service > svc:/system/avahi-bridge-dsd:default is provided. Okay. Does the avahi community expect others to use the DBUS interface directly? That is, do they consider it a Public interface? If so, you need to expose that as part of your ARC case, as well as the SMF service. Now, what bothers me here (assuming that they will someday be useful) is that running the DBUS bits isn't optional at the moment. That is, all calls to the avahi client API go through DBUS and the avahi daemon, and then through the bonjour daemon. That's just very silly. Perhaps the Bonjour daemon could be taught to speak DBUS appropriately? >>> /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? You didn't answer these questions. Danek
