On Fri, Dec 07, 2007 at 12:53:25PM -0500, Dan Williams wrote: > On Fri, 2007-12-07 at 18:14 +0100, Olivier Galibert wrote: > > On Fri, Dec 07, 2007 at 09:37:27AM -0500, Dan Williams wrote: > > > With the pull method, it _would_ still be done on changes. The things > > > that care listen for signals from NM about when the things change, and > > > when they do, they pull the info out of NM. Nothing here needs to poll > > > to get the info it wants. > > > > Color me confused, if NM sends a message to say "DNS config has > > changed", why doesn't it put the new configuration in the message? > > Why the extra round trip? > > Depends; if it's all the DHCP parameters, that's a lot of information to > spam the bus with when possibly nobody will be listening. Maybe it > doesn't matter because maybe most people DHCP-returned option list isn't > large. > > When I really meant with push vs. pull was that currently, > NetworkManager itself has all the D-Bus code to invoke method calls on > named. That's heavy-pushing, you might almost call it > poking-with-a-telephone-pole. I don't want to do that anymore, not for > named and not for anything else either. > > I'm perfectly fine with pushing out the information in the D-Bus signal. > If We are talking about pull style best will be send only SIGHUP when DNS related information is changed. This approach will avoid linking against libdbus (server oriented upstreams don't like it and keep "DBUS" patches downstream isn't nice solution). With SIGHUP We will siply write scripts to get all information from dbus (for example with dbus-send utility) and from server siply call that script which does all needed work (as Simo wrote). Sounds like best for me because maintenance and scalability of those scripts will be really easy. Adam -- Adam Tkac, Red Hat, Inc. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
