On Mon, July 14, 2014 00:41, David Robillard wrote: > 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. >
David, that's an interesting idea! If there is an existing definition say for 'OSC Transport Control' that provides semantics for the topic it could be re-used by other OSC units that share this aspect. Definitions of such units could reference existing definitions and sort them in at any path (preferably as a non-mixed subtree). Example: /my/path/logic /osct/<all appearing below is following 'OSC Transport Control' semantics, defined <here>> This would allow to re-use commonly used aspects. It's to some degree comparable to XML namespaces. oschema is ready to describe re-usable aspects. Missing is a way to reference existing such definitions within others and pin to a place in the tree. (notated) Another thing brought up was discovery. It would be thinkable that one defines this as an aspect of an OSC unit. Units referencing that aspect would for instance send back the definition as a serialized blob when pinged with <possible prefix>/describe. This is just an example not fully thought trough. Little focus was given to dynamic APIs which might be wrong. A classical API of a compiled program / library is quite static. Interpreted programs can have dynamic APIs, i.e. methods added or removed at runtime. So both are possible and have their merit. An example to mention is when the path of the messages reflect a dynamically built hierarchy of things. If the API is dynamic (where the variable parts are not limited to the "args" of pre-defined static messages) so could be the definition. If we have rule-based APIs with either many similar or infinite possible forms a message can take, we loose the benefit of a concrete lookup set of messages. On the other hand there should be a way to express a catch-all handler similar to /* etc. This needs more thinking, input is welcome. -- Thomas _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
