Re: Zeroconf applet

[Rodrigo Moya <rodrigo novell com>]

On Tue, 2006-07-18 at 14:02 -0700, Alan Gibson wrote:
> On 7/18/06, Rodney Dawes <dobey novell com> wrote:
> > It seems like both of these could be merged into one single option,
> > which is "Enable Zeroconf Broadcasting" but with better terminology.
> > This could also just be placed in the Network preferences, rather
> > than having a whole new capplet for it.
> 
> sorry, i meant to suggest that it go into Networking; no point in a
> new capplet at all.
> 
> what im imagining is an extra tab in Networking. It would have 3 radio
> buttons: 1. Enable Zeroconf service announcements (or something like
> that) 2. Disable zeroconf service announcements 3. Set by application
> 
> selecting 3 would turn on a checkbox list of all currently installed
> zeroconf-enabled apps. unchecking would set whatever configuration
> options that app required to disable zeroconf (and if it is a service,
> restart it); checking it would do the reverse.
> 
> > The real questions is whether
> > the policy belongs in Avahi, or something a bit higher. Basically,
> > the policy would be based on the option and enable/disable broadcasting
> > for that user. If the policy is in Avahi, the daemon can be told of the
> > settings change, via dbus. If the policy is higher up on the desktop
> > somewhere, I'm not sure how exactly it would work.
> 
> it would be very slick if we could tell Avahi to not pass messages for
> a certain user or application, but i dont think its possible at the
> this moment. so if one wanted centralized control of what apps publish
> zeroconf info, and i admit it may be too complicated to be worthwhile,
> it seems like it would have to be done on the desktop level. but if
> one wanted to set restrictions by user, it seems like it would almost
> have to go into Avahi. therefore patching Avahi to support
> restrictions by user and application might be the way to go. that
> would definiately go along way toward getting over the objections of
> the security minded.
> 
for that, we might want to have some sort of high-level API for GNOME
apps to use which does the centralized control. If not, making changes
in each app might be too prone for errors
-- 
Rodrigo Moya <rodrigo novell com>