Re: Moving to *Avahi* over howl

[James Henstridge <james jamesh id au>]

Lennart Poettering wrote:

>On Fri, 16.09.05 14:21, James Henstridge (james jamesh id au) wrote:
>
>  
>
>>Alex Graveley wrote:
>>
>>    
>>
>>>Does anyone have any sort of convincing argument as to why an API
>>>abstraction in this case is *needed*?
>>>
>>>("I like abstractions" is not an argument.)
>>>      
>>>
>>Alternatively:
>>
>>If an abstraction is required, is Avahi's dbus interface a suitable
>>abstraction?
>>    
>>
>
>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.
>  
>
Okay. Are you saying "Bonjour/Howl would not be able to implement the
full Avahi dbus API" or "the subset of the Avahi dbus API covering the
common functionality of Avahi/Bonjour/Howl could not be used to write
useful programs"?

If it is just the first, then this idea could still be useful. It would
also make the Avahi client API more desirable:

    * for simple service publishing/discovery, it can interoperate with
      whatever responder is running on the system (with the appropriate
      dbus shim).
    * provides advanced service discovery when used in conjunction with
      the Avahi responder.


>For a abstraction layer you need some kind of least common
>denominator, which is not what Avahi is about.
>  
>
I am not suggesting that you limit the functionality of Avahi to the LCD.

>It's like using the POSIX API (including fork()) as an abstraction
>layer for operating systems like MS-DOS.
>  
>
Sure, but the C library for MS-DOS compilers provides a lot of common
functionality with what you see on a POSIX system (ANSI functions like
printf, etc). If a program only uses APIs that are common to both
platforms then the program will be portable.

With the current Bonjour/Howl/Avahi packages, we have different APIs for
the common functionality, so programs only using the common
functionality still need porting.

James.