26 Mar
2005
26 Mar
'05
8:43 a.m.
Hi Steve,
Was testing this scenario today, which may look familiar to you:
- I created a server with some methods: '/ping/documentation' and
'/osc-schema/documentation', both of which use the same handler 'doc'.
- I send query '/*/documentation' to the server.
- 'doc' got called twice with path '/*/documentation'.
The unexpanded path makes it impossible for the handler to determine
what container was intended. In my interpretation the OSC spec is not
completely explicit on this point, but I think the intention was to
send the expanded path to the handler. The spec is specific in stating
that '*' is invalid in an OSC method, and it talks about the "OSC Address
of a OSC Method".
Initially I hacked liblo to always send the expanded path. However, the
result was also that the generic method handler (oh, I used that too :)
got called with a NULL path. Since that is useless to that handler it
seems best to me to use the unexpanded path for this case.
The resulting patch is applied. Please let me know your view on this.
Cheers,
--
Martin
---------------------------------------------------------------------------
Index: liblo/src/server.c
===================================================================
--- liblo.orig/src/server.c 2005-03-02 19:15:47.000000000 +0000
+++ liblo/src/server.c 2005-03-26 11:33:41.000000000 +0000
@@ -463,6 +463,7 @@
lo_address src = lo_address_new(NULL, NULL);
char hostname[LO_HOST_SIZE];
char portname[32];
+ const char *pptr;
free(msg->types);
msg->types = types;
@@ -542,7 +543,13 @@
}
}
- ret = it->handler(path, types, argv, argc, msg,
+ /* Send wildcard path to generic handler, expanded path
+ to others.
+ */
+ pptr = path;
+ if (it->path) pptr = it->path;
+
+ ret = it->handler(pptr, types, argv, argc, msg,
it->user_data);
} else if (lo_can_coerce_spec(types, it->typespec)) {
@@ -572,7 +579,13 @@
}
endian_fixed = 1;
- ret = it->handler(path, it->typespec, argv, argc, msg,
+ /* Send wildcard path to generic handler, expanded path
+ to others.
+ */
+ pptr = path;
+ if (it->path) pptr = it->path;
+
+ ret = it->handler(pptr, it->typespec, argv, argc, msg,
it->user_data);
free(argv);
free(data_co);
27 Mar
27 Mar
8:30 p.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Sat, Mar 26, 2005 at 12:43:45PM +0000, Martin Habets wrote:
Hi Steve,
Was testing this scenario today, which may look familiar to you:
- I created a server with some methods: '/ping/documentation' and
'/osc-schema/documentation', both of which use the same handler 'doc'.
- I send query '/*/documentation' to the server.
- 'doc' got called twice with path '/*/documentation'.
The unexpanded path makes it impossible for the handler to determine
what container was intended. In my interpretation the OSC spec is not
completely explicit on this point, but I think the intention was to
send the expanded path to the handler. The spec is specific in stating
that '*' is invalid in an OSC method, and it talks about the "OSC Address
of a OSC Method".
That sounds good, its just an oversight on my part, the patch makes
perfect sense to me. I'l apply it when I get the chance
FWIW, I'm planning to add API support for the documentation etc. features
at some point, I do the sub-path listing stuff allready. But, I'l make sure
I dont stomp on anything done explicitly by developers.
- Steve
30 Mar
30 Mar
8:02 p.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Mon, Mar 28, 2005 at 12:30:30AM +0100, Steve Harris wrote:
That sounds good, its just an oversight on my part,
the patch makes
perfect sense to me. I'l apply it when I get the chance
thanks.
FWIW, I'm planning to add API support for the
documentation etc. features
at some point, I do the sub-path listing stuff allready. But, I'l make sure
I dont stomp on anything done explicitly by developers.
I'll have to try and get this output. So far no luck because as I'm
testing with sendOSC. Can't get dumpOSC to run on the same port, but
havent looked at the code yet.
Am working on a library for this stuff + service discovery on top of
liblo. Sub-path listing is the only thing I haven't coded up yet. Still
a good deal of testing to do.
--
Martin
31 Mar
31 Mar
11:07 a.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Thu, Mar 31, 2005 at 12:02:15 +0100, Martin Habets wrote:
On Mon, Mar 28, 2005 at 12:30:30AM +0100, Steve Harris
wrote:
You might want to get in touch with Dave robillard (sp?) as he's working
on something similar.
- Steve
That sounds good, its just an oversight on my
part, the patch makes
perfect sense to me. I'l apply it when I get the chance
thanks.
FWIW, I'm planning to add API support for the
documentation etc. features
at some point, I do the sub-path listing stuff allready. But, I'l make sure
I dont stomp on anything done explicitly by developers.
I'll have to try and get this output. So far no luck because as I'm
testing with sendOSC. Can't get dumpOSC to run on the same port, but
havent looked at the code yet.
Am working on a library for this stuff + service discovery on top of
liblo. Sub-path listing is the only thing I haven't coded up yet. Still
a good deal of testing to do.
4 Apr
4 Apr
2:04 p.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Thu, Mar 31, 2005 at 03:07:28PM +0100, Steve Harris wrote:
Yes, we had a nice discussion a while back. Here's a recap of his scenario:
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
Am working on
a library for this stuff + service discovery on top of
liblo. Sub-path listing is the only thing I haven't coded up yet. Still
a good deal of testing to do.
You might want to get in touch with Dave robillard (sp?) as he's working
on something similar. 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.
--
Martin
11:28 p.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Mon, 2005-04-04 at 17:02 +0100, Martin Habets wrote:
On Thu, Mar 31, 2005 at 03:07:28PM +0100, Steve Harris
wrote:
Yes, we had a nice discussion a while back. Here's a recap of his scenario:
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..
Am
working on a library for this stuff + service discovery on top of
liblo. Sub-path listing is the only thing I haven't coded up yet. Still
a good deal of testing to do.
You might want to get in touch with Dave robillard (sp?) as he's working
on something similar. 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. > > 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.
-DR-
5 Apr
5 Apr
7:48 a.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Tue, Apr 05, 2005 at 11:18:12AM -0400, Dave Robillard wrote:
I agree FWIW, as long as its generic.
- Steve
> > 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. 
6 Apr
6 Apr
6:31 a.m.
New subject: [linux-audio-dev] GPL concerns
Hey everyone. I have a bland but important question for everyone. Say
hypothetically a company is developing an audio product using lots of
GPL source, but for whatever marketing reasons asks for NDA concerning
the codebase. Lots of GPL work is referenced and at least dynamically
linked, and though the company has directly stated that it will release
the codebase publicly with the product release (once it is complete).
I am curious as to the general feel in the community on such practices.
Would this 1) be a violation of the GPL, 2) if it is how tolerant would
the OSS community be, considering the general good intent of the
project, and 3) if I were asked to sign such a NDA would that document
be a binding agreement even if the NDA itself might be a violation of
the GPL since it is inherently counterintuitive to the intent of the
GPL.
Anyway, I know some of you have already been there with the fun NDA
stuff and thought you the best bunch of people to ask before getting
myself stuck in a NDA I am not completely comfortable with. The current
project cycle (hypothetically) is two years. I know this is happening
in the industry quite frequently already, but I am not sure I completely
agree or disagree with the practice (assuming the codebase does make it
into the public domain). On one hand I can sympathize with the
difficulties involved in bringing new products to market and how leaks
in early design phases can undercut profits enormously. On the
otherhand I would love to see more companies taking an open and
community approach to product development such as open ICs, and even
open business management. I am sure this would happen a lot more if
such efforts were a tax write off :), but then we live in the world we
live in.
Any thoughts, references to successful business models concerning
hardware development with free software, and legal cautions are all
greatly appreciated.
Yours truly,
Shane
PS I apologize in advance for any redundancy on this subject :).
7:18 a.m.
New subject: [linux-audio-dev] GPL concerns
RTFF (Read The Fine FAQ), please.
See:
Does the GPL allow me to distribute a modified or beta version under a
nondisclosure agreement?
http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowNDA
Does the GPL allow me to develop a modified version under a nondisclosure
agreement?
http://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
Frequently Asked Questions about the GNU GPL
http://www.gnu.org/licenses/gpl-faq.html
Licenses
http://www.gnu.org/licenses/licenses.html
Cheers,
Andreas
----- Original Message -----
From: "Shane" <lists(a)itsagesolutions.com>
To: <linux-audio-dev(a)music.columbia.edu>
Sent: Wednesday, April 06, 2005 7:31 AM
Subject: [linux-audio-dev] GPL concerns
Hey everyone. I have a bland but important question
for everyone. Say
hypothetically a company is developing an audio product using lots of
GPL source, but for whatever marketing reasons asks for NDA concerning
the codebase. Lots of GPL work is referenced and at least dynamically
linked, and though the company has directly stated that it will release
the codebase publicly with the product release (once it is complete).
I am curious as to the general feel in the community on such practices.
Would this 1) be a violation of the GPL, 2) if it is how tolerant would
the OSS community be, considering the general good intent of the
project, and 3) if I were asked to sign such a NDA would that document
be a binding agreement even if the NDA itself might be a violation of
the GPL since it is inherently counterintuitive to the intent of the
GPL.
Anyway, I know some of you have already been there with the fun NDA
stuff and thought you the best bunch of people to ask before getting
myself stuck in a NDA I am not completely comfortable with. The current
project cycle (hypothetically) is two years. I know this is happening
in the industry quite frequently already, but I am not sure I completely
agree or disagree with the practice (assuming the codebase does make it
into the public domain). On one hand I can sympathize with the
difficulties involved in bringing new products to market and how leaks
in early design phases can undercut profits enormously. On the
otherhand I would love to see more companies taking an open and
community approach to product development such as open ICs, and even
open business management. I am sure this would happen a lot more if
such efforts were a tax write off :), but then we live in the world we
live in.
Any thoughts, references to successful business models concerning
hardware development with free software, and legal cautions are all
greatly appreciated.
Yours truly,
Shane
PS I apologize in advance for any redundancy on this subject :).
10:09 a.m.
New subject: [linux-audio-dev] GPL concerns
On Wed, 06 Apr 2005 00:31:15 -0500
Shane <lists(a)itsagesolutions.com> wrote:
Hey everyone. I have a bland but important question
for everyone. Say
hypothetically a company is developing an audio product using lots of
GPL source, but for whatever marketing reasons asks for NDA concerning
the codebase. Lots of GPL work is referenced and at least dynamically
linked, and though the company has directly stated that it will release
the codebase publicly with the product release (once it is complete).
I am curious as to the general feel in the community on such practices.
Would this 1) be a violation of the GPL,
Yes.
2) if it is how tolerant would
the OSS community be, considering the general good intent of the
project, and
If any of my code is involved, I will prusue the matter.
3) if I were asked to sign such a NDA would that
document
be a binding agreement even if the NDA itself might be a violation of
the GPL since it is inherently counterintuitive to the intent of the
GPL.
The GPL is pretty clear about this. The GPL comes into action when
the binaries or code derived from GPL code is **distributed**.
That means that you and the company can hack on whatever GPL code
you like as long as they don't release a binary (under NDA or not).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Therapists typically base the nuttiness of a patient on the
strength of their convictions, on which basis this 43,000 word
opus alone stands as a kind of testament to Bill's (Gates)
madness." - The Register
5 Apr
5 Apr
11:38 a.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
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().
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.
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.
--
Martin
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. > > 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.
11:14 p.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
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.
6 Apr
6 Apr
8:08 a.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
On Wed, Apr 06, 2005 at 11:14:03AM -0400, Dave Robillard wrote:
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 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.
I know how rendezvous works. But a client_id is not sufficient, so
why expect applications to provide such data?
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.
--
Martin
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(). 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.
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?
9:10 a.m.
New subject: [linux-audio-dev] Re: [OSC_dev] [PATCH] liblo & pattern matching callback
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-
7107
days inactive
7118
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
6 participants
participants (6)
-
Andreas Kuckartz -
Dave Robillard -
Erik de Castro Lopo -
Martin Habets -
Shane -
Steve Harris