Re: Moving to *Avahi* over howl

[JP Rosevear <jpr novell com>]

On Mon, 2005-09-19 at 17:53 +0200, Alexander Larsson wrote:
> On Mon, 2005-09-19 at 11:16 -0400, JP Rosevear wrote:
> > On Fri, 2005-09-16 at 15:57 +0100, Jono Bacon wrote:
> > > On 9/16/05, Lennart Poettering <mztabzr 0pointer de> wrote:
> > > > I doubt this a good idea. Avahi's DBUS interface reflects what Avahi
> > > > is capable of and is in no way a generic DNS-SD API. In fact, Avahi is
> > > > more powerful than either Howl or the Bonjour in many
> > > > respects. Writing a bridge to access Howl/Bonjour via that DBUS API
> > > > would be exceptionally kludgy if not impossible.
> > > 
> > > This is a policy decision. If an abstraction layer was used to
> > > abstract away any possible implementation of a technology, GNOME would
> > > bloat to hell.
> > 
> > A thin abstraction layer is not bloat especially when you are are tieing
> > in at lower an lower levels of the system.  What happens for instance if
> > windows Vista has its own zeroconf implementation, it would be better to
> > tie in there.  Or if gnome-keyring would rather use Apple's secret store
> > instead of its default.
> 
> What if windows had its own version of evolution-data-server, or
> gnome-vfs, or widget toolkit, should we unconditionally use those? There
> is always a line that has to be drawn where we do our own, and where we
> use the system stuff. In this case its not that clear-cut.

Unconditionally?  Of course not - e-d-s is already an abstraction layer,
you can write pluggable backends.  We already have native backends in
the widget toolkit for windows, framebuffer, etc.

Basically I was trying to say that having an abstraction layer is not
automatic bloat.

> Since DNS-SD is pretty close to the system-level its not at all
> unreasonable that we should use the system-specific implementation. On
> the other hand, Avahi clearly looks like the best choice on Linux and
> other free UNIXes, so almost all Gnome users would use that, and would
> pay for the extra layer unnecessarily.

You also arguing against using something "uncondtionally" above, which
is exactly what you are promoting here.

It would seem in cases where we've had different implementations in the
past, or multiple implementations of the same thing, this would suggest
an opportunity for an abstraction layer.

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.