Closed crotwell closed 9 months ago
Probably for syntax simplicity, patterns should be allowed even if they don't make sense (INFO ID).
In case of INFO CONNECTIONS, patterns could be used to, eg., get connections that are using certain stations.
This is my personal opinion.
Agreed that this should be better explained in the spec.
Perhaps break the INFO section into separate sections for each subcommand, like how is currently done with DATA [seq]
and DATA seq start_time [end_time] {CAP:TIME}
, so each subcommand has its own explanation and list of allowed parameters?
+1 on the new table.
All the parenthesis in the new table make it harder to see the actual meaningful character. Perhaps this was for formatting but didn't work correctly?
Recommend changing (-)
to just -
or some other easier to see text.
Parenthesis removed.
+1 on proposed change.
Looking at the INFO command, it is not clear to me when the optional station/stream/format parameters can be used.
Presumably, there should never be any extra parameters for "INFO ID" and I suspect they don't make sense for "INFO CONNECTIONS". Would be helpful if this were explained. Perhaps give a couple of examples?