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-