OSCQueryProposal
OSCQueryProposal copied to clipboard
method with contents?
Is there any reason that an OSC method actually has to be a leaf?
The proposal references the OSC spec and provides this bullet point:
An OSC server's OSC Methods are arranged in a tree structure called an OSC Address Space. The leaves of this tree are the OSC Methods and the branch nodes are called OSC Containers.
but, for instance, libossia let me create this:
{
"FULL_PATH": "/",
"CONTENTS": {
"foo": {
"FULL_PATH": "/foo",
"TYPE": "f",
"VALUE": 0.5,
"ACCESS": 3,
"CLIPMODE": "none",
"CONTENTS": {
"bar": {
"FULL_PATH": "/foo/bar",
"TYPE": "ff",
"VALUE": [
1,
2
],
"ACCESS": 3,
"CLIPMODE": "none",
"EXTENDED_TYPE": "vecf"
}
}
}
}
}
This doesn't seem like it would cause a problem..
Hi @x37v I don't think this is a problem at all. At least, it works with ossia, indeed.
Is it the fact that an address can be a container and a leaf at the same time that puzzles you ?
Hi @x37v I don't think this is a problem at all. At least, it works with ossia, indeed.
Is it the fact that an address can be a container and a leaf at the same time that puzzles you ?
I'm not actually puzzled, I'm implementing a model for this: https://github.com/x37v/oscquery-rs and currently it doesn't allow for methods with contents, because of that bullet point referenced in the proposal.
It isn't a big deal though, easy to make the model more relaxed.
Thanks @bltzr
yep, originally we did it strictly but a lot of people wanted to be able to do that and, as you said, relaxing the restriction doesn't cost much...
maybe it's time to write a clarified OSC spec that takes into account 2020 practices
yep, originally we did it strictly but a lot of people wanted to be able to do that and, as you said, relaxing the restriction doesn't cost much...
maybe it's time to write a clarified OSC spec that takes into account 2020 practices
Great, thanks @jcelerier