Re: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback

On Tue, Apr 05, 2005 at 11:18:12AM -0400, Dave Robillard wrote:
> > On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
> > > Implementation wise, the scheme goes something like this:
> > >
> > > - client broadcasts it's existance via rendezvous
> > > - patching server replies to client, so now both are aware of each
> > > other's existance
> > > - (any) client can now set destinations for client. in other words,
> > > osc-patch-bay functionality now works
> > >
> > > When a destination is added/removed, the patching server will notify the
> > > client (via OSC), and the client will update it's list of destinations
> > > appropriately (this will all be abstracted by liblo's API though).
> >
> > Dave, do have any more details on this? i.e. the suggested OSC addresses to
> > add/remove a destination.
>
> Well, I've talked a bit more with Steve about this, and have separated
> this 'patch bay' stuff from actual service discovery conceptually
> (though one depends on the other of course).
>
> Basically we just need a lo_discover(client_id_string) method that
> allows figuring out what clients are out there (optionally, with the
> given name). I started to implement this but it got pushed down the
> priority list to make room for some more important/urgent things..

This would be nice for applications wanting a service, but is not an
absolute necessity. However, applications providing a service must allow
for some OSC addresses to be used by the library to add/remove a destination.
For example (a bad one), the application itself could not use
"/destination/add" and "/destination/remove".
The second thing applications providing a service need is ways to send a
message to all/some destinations.
Third, if integrated into liblo they need a way to pass their client_id
to something like lo_server_new().

The use of a client_id is oversimplifying the situation too much IMO.
What applications realy want to provide/discover are clients providing a
service using a certain OSC namespace. A client_id is no use for this,
unless you hardcode them to map to namespaces.

> > > > Am working on a library for this stuff + service discovery on top
> > > > of liblo.
>
> Hmm. Not sure I like the sound of that. Service discovery belongs
> inside liblo itself, IMO.

liblo only provides OSC messaging at the moment. To me it is safest to
initially do these kinds of extensions separately, at least until the
API stabilizes. If Steve is willing to merge it into liblo after that,
that would be great.

-- 
Martin