On Tue, 2005-05-04 at 13:40 +0100, Martin Habets wrote:
> 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().
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 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.
> > > > > 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.
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?
-DR-
Received on Wed Apr 6 08:15:05 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 06 2005 - 08:15:06 EEST