6 Apr
2005
6 Apr
'05
9:10 a.m.
On Wed, 2005-06-04 at 11:08 +0100, Martin Habets wrote:
I know how rendezvous works. But a client_id is not sufficient, so
why expect applications to provide such data?
It's plenty sufficient. If sooperlooper wants its UI, it can just look
for sooperlooper_gui. Many things might want to find "supercollider".
The only dependancy between the two is that one (patching) depends on
the other (service discovery).
Service discovery has tons of uses outside of a patch-bay like system
(ie the above sooperlooper scenario, etc)
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.
No, it will be done with backwards compatible API additions.
lo_broadcast, etc.
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. 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. 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.
That's because you're mashing the two problems together in your head,
which makes it seem WAY more complicated than it actually is. I thought
the exact same way before Steve knocked some sense into me. :)
Trust me, as far as tackling the problem, consider service discovery as
a completely different thing. That's needs to be done, THEN a patch bay
system can be built.
It's not a difficult problem at all - look at the howl examples. The
only difficult part is figuring out how to fit it nicely into liblo.
-DR-