On Wed, 2005-06-04 at 11:08 +0100, Martin Habets wrote:
> 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.
>
> 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 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.
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)
> 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-
Received on Wed Apr 6 16:15:07 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 06 2005 - 16:15:07 EEST