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

On Wed, Apr 06, 2005 at 11:14:03AM -0400, Dave Robillard wrote:
> > > 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().
>
> Yes, as far as the (seperate) patch bay stuff, some OSC methods will
> need to be set aside for those sorts of things. With a reasonable
> prefix it shouldn't be a problem.

The thing is that you don't just need 1 new function in liblo, but a number
of them.
Modifying something like lo_server_new() leads to an API change, which
should IMO be prevented if possible.

> > 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.
>
> Rendezvous works by having text string IDs. You need /some/ sort of ID
> anyway - if not a text identifier, then what? Noone said all apps have
> to use things based on the text identifier, you can enumerate all
> available apps of course.

I know how rendezvous works. But a client_id is not sufficient, so
why expect applications to provide such data?

> The namespace is actually a seperate problem from the service discovery
> entirely, as it takes place in OSC - ie after the service has already
> been discovered. Steve is doing/has done some work in this area already
> I think, though I havn't played with it.

The namespace is not the problem here, it is the solution. Yes, OSC and
service discovery are separate things. But it's the usage of both
technologies that leads to acceptable results for all applications.
If a library API does not provide added functionality there isn't that
much reason for it's existance at all.

> > 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.
>
> It's not the most difficult problem in the world, and the implementation
> would be almost 100% different in liblo as opposed to a library anyway.
> Why waste the time writing some library on top of liblo just to
> immediately rewrite it anyway?

I think you underestimate the complexity of this issue, as you keep saying
things are not a problem.
You've lost me on the 100% different part: liblo is a library. Wether
functionality is implemented in liba or libb does not make any difference
as to it's implementation. As such there is no need for any rewrite.

I have no doubt your solution will work for the application you have in
mind. But I find it impossible to apply you logic to other scenarios/usages.

-- 
Martin