Change Details

This is a first take at tackling a problem caused by avahi going out of service -- usually its restart during an upgrade. In the current state, these things happen: - kdnssd holds dbus paths of avahi objects that no longer exist. Eventually, it calls methods on those paths, which might or might not exist or designate different objects - the client won't discover that published addresses/browsing addresses etc. don't work anymore. Ironically (this happens with kopete), the client will get some error message in the moment avahi comes //alive// again, not when it's going dead - KDNSSD objects used with this avahi instance stop working, and are unusable in the future In this diff, mostly the first problem is tackled. I add a new singleton class, ##AvahiDisconnectListener##, which will provide a signal when avahi goes away. Every KDNSSD object would listen for that signal and perform the necessary cleanup. This means, in this diff, mostly deleting dbus objects and clearing dbus addresses. On top of that, the ##PublicService## class is changed that it reports failure to publish with a ##published(false)## signal, and a ##RemoteService## reports failure with ##resolved(false)##. The latter should be able to restart when convienient with ##resolveAsync##. Other objects are simply left in a consistent, but nonworking state and can't be used anymore, because they lack the signals to signal error, and methods to restart their operations. Looking forward, this patch could be extended by adding aforementioned error signals, or even, providing a much better user experience, automatically restarting normal operation when avahi comes on again. That information is doable in the client, but is tedious and error prone, as it needs listening for DBus ##NameOwnerChanged##, and then correctly wait because Avahi isn't ready for business right away. Also, you need to manage all the race conditions.

This is a first take at tackling a problem caused by avahi going out of service -- usually its restart during an upgrade. In the current state, these things happen: - kdnssd holds dbus paths of avahi objects that no longer exist. Eventually, it calls methods on those paths, which might or might not exist or designate different objects - the client won't discover that published addresses/browsing addresses etc. don't work anymore. Ironically (this happens with kopete), the client will get some error message in the moment avahi comes //alive// again, not when it's going dead - KDNSSD objects used with this avahi instance stop working, and are unusable in the future In this diff, mostly the first problem is tackled. I add a new singleton class, ##AvahiDisconnectListener##, which will provide a signal when avahi goes away. Every KDNSSD object would listen for that signal and perform the necessary cleanup. This means, in this diff, mostly deleting dbus objects and clearing dbus addresses. On top of that, the ##PublicService## class is changed that it reports failure to publish with a ##published(false)## signal, and a ##RemoteService## reports failure with ##resolved(false)##. The latter should be able to restart when convienient with ##resolveAsync##. Other objects are simply left in a consistent, but nonworking state and can't be used anymore, because they lack the signals to signal error, and methods to restart their operations. Looking forward, this patch could be extended by adding aforementioned error signals, or even, providing a much better user experience, automatically restarting normal operation when avahi comes on again. That information is doable in the client, but is tedious and error prone, as it needs listening for DBus ##NameOwnerChanged##, and then correctly wait because Avahi isn't ready for business right away. Also, you need to manage all the race conditions.

This is a first take at tackling a problem caused by avahi going out of service -- usually its restart during an upgrade. In the current state, these things happen: - kdnssd holds dbus paths of avahi objects that no longer exist. Eventually, it calls methods on those paths, which might or might not exist or designate different objects - the client won't discover that published addresses/browsing addresses etc. don't work anymore. Ironically (this happens with kopete), the client will get some error message in the moment avahi comes //alive// again, not when it's going dead - KDNSSD objects used with this avahi instance stop working, and are unusable in the future In this diff, mostly the first problem is tackled. I add a new singleton class, ##AvahiDisconnectListener##, which will provide a signal when avahi goes away. Every KDNSSD object would listen for that signal and perform the necessary cleanup. This means, in this diff, mostly deleting dbus objects and clearing dbus addresses. On top of that, the ##PublicService## class is changed that it reports failure to publish with a ##published(false)## signal, and a ##RemoteService## reports failure with ##resolved(false)##. The latter should be able to restart when convienient with ##resolveAsync##. Other objects are simply left in a consistent, but nonworking state and can't be used anymore, because they lack the signals to signal error, and methods to restart their operations. Looking forward, this patch could be extended by adding aforementioned error signals, or even, providing a much better user experience, automatically restarting normal operation when avahi comes on again. That information is doable in the client, but is tedious and error prone, as it needs listening for DBus ##NameOwnerChanged##, and then correctly wait because Avahi isn't ready for business right away. Also, you need to manage all the race conditions.