14 Jul
2014
14 Jul
'14
7:14 p.m.
On Mon, July 14, 2014 00:41, David Robillard wrote:
On Wed, 2014-07-09 at 15:22 +0200, tom(a)trellis.ch
wrote:
[...]
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
(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.