zeroconf, namespace querying

Hello,

We've recently had a short discussion on the liblo mailing list
regarding a proposed patch to enable Avahi/Zeroconf support.
OSC servers created with liblo would announce themselves on zeroconf
with the service '_udp._osc'.

Some interesting comments followed, and the issue of namespace
querying was brought up.
(i.e., if you announce yourself on the network, some known way of
finding out what you can _do_ is quite useful.)

I thought I'd bring up the issue here, as this has become more of an
OSC issue than for any specific implementation.  These two points are
quite important for OSC, I think, because service discovery and
namespace querying are two functions often needed for OSC servers that
are not really yet standardized.  There have been several proposals,
but as far as I know nothing has been dubbed 'official' for the OSC
spec.  The longer this remains unofficial, the more people will
implement incompatible ways of solving these problems.

Now that we are considering adding zeroconf support to liblo, we'd
like to ensure it follows (or leads) some kind of standard that might
be compatible with other OSC implementations.

Some of the proposals thus far that I know of:

- Natually, OSC does not impose anything about what messages should do
what, however I think one of the original OSC papers suggested using
/namespace to enumerate accepted messages.  Unfortunately it didn't
specify what kind of message should be used as a response to the
/namespace message.

- The 2006 meeting minutes suggest using simply the address with a '/'
appended: http://opensoundcontrol.org/publication/nime-2006-osc-developers-meeting

- It also mentioned discovery via zeroconf which was later implemented
by Rémy Müller in the "oscbonjour" object for Max/MSP.

- Service discovery was mentioned in a paper I wrote last year with
Joseph Malloch:
http://www.idmil.org/_media/wiki/icmc2007_malloch_mapping.pdf

We implemented it using only OSC and a multicast port, instead of
going towards use of external services like ZeroConf.  Additionally
this solution addresses namespace querying via the /namespace message,
with a response containing Jamoma-like @-tagged parameters.

- Andrew Schmeder and Matt Wright proposed in 2004 using #-prepended
addresses to contain special commands such as #reply, #documentation,
#type-signature, to give information about namespaces.  This is
intentionally consistent with http GET queries.
http://opensoundcontrol.org/publication/query-system-open-sound-control

How have hardware vendors approached this problem?  I don't know about
the Lemur, but I know that in the case of the Kroonde, instead of
using any kind of announce support, it simply sends all messages to
'broadcast'.  (I don't know if this is configurable..)  This is
presumably with the expectation that the device will be connected over
a dedicated connection to a single computer or very small network.
While it definitely makes configuration easy, it would also horribly
flood any network one is tempted to connect it to.

In this liblo-devel thread, Lars Luthman suggests we should follow the
D-Bus introspection specification, which can be found here:
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable

Also, Steve Harris suggests that we should use mDNS records to
announce more than just '_udp._osc', but include some descriptive
fields such as a URI with information on the service.
I don't really know enough about mDNS to say much more about this, so
I'll try to read up on it.

The thread on the liblo mailing list that I mention can be seen here
for your reference:
http://sourceforge.net/mailarchive/forum.php?thread_name=9b3e2dc20802212025m1d34fc3frcc974c00bba6b025%40mail.gmail.com&forum_name=liblo-devel

I think we need to open up and continue discussions on these topics if
we want to make OSC more generally useful as a messaging protocol.


cheers,
Steve Sinclair
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev