5 Apr
2005
5 Apr
'05
11:14 p.m.
On Tue, 2005-05-04 at 13:40 +0100, Martin Habets wrote:
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-
On Tue, Apr 05, 2005 at 11:18:12AM -0400, Dave
Robillard wrote:
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.
On Tue,
Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
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.. 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. 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.