On Wed, Apr 06, 2005 at 11:14:03AM -0400, Dave Robillard wrote:
Basically we just need a lo_discover(client_id_string)
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
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
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.
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.