On Wed, 2014-07-09 at 15:22 +0200, [email protected] wrote: [...] > > (enumerated paths being /foo/bar1/ /foo/bar2/ /foo/bar100/) > > There was some reference to patterns, but at first glance they didn't > > quite look applicable. > > There is currently nothing foreseen to handle that kind of redundancy. > Still it's possible to describe such messages. To me it looks like a > /foo/bar i would be easier to handle. I wouldn't go so far and say that > kind of API (enumerated path') is just not well designed.
To account for things like this, a good schema would need to detach the paths from the "support", then provide a mechanism to match the two based on path patters. So, you could say things like: control_support = "<path> supports '<path>/control f' messages" then "any path that matches '/knobby_bits/*' supports control_support" or something along those lines. Then apps with a bunch of dynamic paths that all follow a common control scheme are fine. Disclaimer: Knee-jerk response, I haven't read the schema -- dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
