Re: [liblo] patch for avahi support

Hi,

Some really good points here.
Sounds like everyone's interested in this functionality.

On Fri, Feb 22, 2008 at 5:40 AM, Steve Harris
<S.W...@ec...> wrote:
>  I think I would want an advertising API, something like
>
>  lo_server_thread_advertise(st, id, ...)
>  eg, for jamin:
>   char *extra = g_strdup_printf("file=%s", file_name);
>   lo_server_thread_advertise(st, "http://jamin.sf.net/osc_control",
>  extra);
>
>  MDNS records have a field for putting ID information, like
>  uri=http://... file=...

I definitely like the idea of providing a URL for information on the
expected OSC namespace.
This might be a very useful alternative (or even in addition to)
automatic namespace querying.


>  That implies we'd also want a lo_server_discover() function that scans
>  the available MDNS records, find the OSC ones, does some pattern
>  matching and returns an array of lo_addresses and "extra data" strings
>  or something similar.

Could be useful, sure.  I think it's a distinct functionality though,
being discoverable, and doing the discovering.
But certainly the two go together.

>  lo_server_thread_stop and _start could implicitly publish and
>  unpublish the advert, and lo_server_thread_free() implicitly free the
>  associated data.

It's probably how I'd do it.  I guess the question is more whether it
should be done by default, or if it should require enabling by the
user.
And should it be enabled on a per-server basis, or globally?

I think I'd vote on doing it automatically, unless explicitly disabled
at run-time.  (or configure-time of course.)


>  > The patch makes avahi support optional with a configure flag.
>
>  It's probably a good idea to autodetect, and have -enable and --
>  disable flags, it doesn't really cost anything if it's compiled in but
>  not used.

Sure.


>  > - if an OSC service is announced, does this imply that it should
>  > respond to certain standard messages? as far as I know no such
>  > standard exists.
>
>  Not as far as I know wither, it would have to be per-application and/
>  or emerging consensus.

I guess that discussion belongs on the OSC list.
It's about time someone brought it up again anyway.. :)
Namespace discovery is really is an outstanding issue with OSC, and
the longer it remains unattended, the more people will implement
various incompatible solutions.


>  > Since it's optional at configure time, would it be harmful to have
>  > lo_servers simply always announce on zeroconf if this option is
>  > enabled?
>
>  I think to be useful you have to give them some ID information, so a
>  dedicated client can find a (set of) dedicated server(s). You can
>  imagine for eg. the superlooper client autoconnecting if there's only
>  one server on the local network and put up a request dialogue if there
>  more than one.
>
>  Just knowing that there's some OSC server at osc.udp://
>  192.168.0.1:9999/ is not terribly useful.

Absolutely.  I'll have to read up a bit on avahi/zeroconf to figure
out how to add more information to the announce.
Patches would be accepted here .. ;-)  But it's on my todo list, for sure.



On Fri, Feb 22, 2008 at 5:44 AM, Camille Troillard
<ca...@os...> wrote:
> Is there a specific reason to add "overload" methods to server
> instantiation?
> I think Bonjour service publication is relatively independant from server
> creation, and I would suggest something like:
>
> lo_zeroconf_publish (lo_server *)
> lo_zeroconf_unpublish (lo_server *)

I think your idea looks cleaner, admittedly, but liblo is (in general)
organized such that functions affecting a particular data structure
start with the name of that data structure.  So, since a zeroconf
announce is tied to a lo_server, the function should start with that
in the name, I think.

(Yes, lo_send_message() is a exception to this rule!  arrr..)

On the other hand, if it were made into a global flag that all
lo_servers respect, perhaps the functions could be:

lo_zeroconf_init();
lo_zeroconf_free();

The extra information requested by Steve could be passed to
lo_zeroconf_init()... no wait that doesn't work because each lo_server
will have its own URI.  I guess some lo_server_* function will have to
exist to support this.


> > - Is adding an extra function to initialize zeroconf announcement
> > adding extra complexity?
>
> IMHO, I think so.
> It also adds the need for the developper to learn another API calls, etc.
> I guess the default behaviour would be to publish Bonjour service every a
> server is created.
>
> It would be great to configure the liblo library with a function to disable
> Bonjour.
> The configuration could be done like a global register.

Agreed on both counts.
Well, whether or not configuration should be global is unclear to me.


> If it is not desired to publish every servers (which I think needs to be
> debated), then the default value for the global parameters would be to NOT
> publish the service.  The user would just have to change that switch to
> publish the subsequently created servers.

I'm having a hard time coming up with situations where one would not
like to publish the service.. ;-)
I think doing it by default is probably okay.
Users who are aware of the zeroconf functionality may wish to disable
it, but otherwise I think it's probably safe to use.



On Fri, Feb 22, 2008 at 6:35 AM, Lars Luthman <lar...@gm...> wrote:
>  If someone does decide to implement namespace querying it might be a
>  good idea to make it as similar to the D-Bus Introspection API as
>  possible (see
>  http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable ).
>
>  D-Bus and OSC are already very similar, and lots of programs for Linux
>  (and other GNOME/KDE-using systems) already use D-Bus, so having the
>  introspection methods use the same concepts would be nice.
>
>  Yeah, XML is ugly, but it's there and it obviously works reasonably
>  well.


I don't know enough about D-Bus to make an intelligent comment here,
but your comparison with OSC is interesting.
I think I'll re-post some of this stuff on the OSC list and see if
anyone has any comments there.
What I've read so far about the proposed namespace querying stuff
actually does already look very similar to that introspection XML,
since it's basically a set of names and parameter types.

Another thing to consider is making zeroconf support compatible with
Rémy Müller's "oscbonjour" object for Max/MSP.
(I think the proposed patch is already fairly compatible, but I'd have
to verify.)


Steve