Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

API separators, "=" vs " "

Doug - K3TZR
Doug - K3TZR Member
edited November 2018 in SmartSDR API
Some API commands are in the form <name=value> whereas other are <name value>. I believe individual commands require one form or the other. In future versions could the API be made to accept either separator? That wouldn't break old code but would make the API more consistent.

Comments

  • John G3WGV
    John G3WGV Member ✭✭
    edited November 2018
    This seems like a reasonable suggestion.

    There are similar protocol variations in the command responses which makes parsing more complex. There's probably a perfectly good reason for these differences and I'm not suggesting that any changes need to be made, especially if to do so would damage backward compatibility. Is there an API design document that discusses these differences and the rationale?
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited November 2018
    In general, commands that need parameters have parameters in a "command parameter parameter..." structure.  If the parameters to commands are name/value pairs, then the name/value pairs are separated with = and the parameters are separated with space.  For example:
    radio filter_sharpness DIGITAL level=3 auto_level=0
    Does this help understand why it's this way?  If this doesn't "cover it," please provide some examples we can look at and think about.

    Just as a side note, my original goal was to use a recursive descent parser for the API and I was amazed that the tools to do this in C were awful.  I made several aborted attempts at it while the API was growing and finally gave up on the idea (too much to do, so little time).  As a result, the API is parsed with CRT primitives (strnlen, strncmp, etc).  Altering an API that does not have a grammar codified is considerably harder.  The method we ended up with is also responsible for any inconsistencies you see.  Having said this, we have altered some commands for required updates and made it so they would work with either a past or new format (slice is an example).  With so many programs using the API at this point, we would have to look carefully at any changes, especially sweeping ones.
  • John G3WGV
    John G3WGV Member ✭✭
    edited July 2017
    Great reply, thanks Steve.

    I don't think this is worth spending time on - we've gotten used to the API's little quirks and it isn't really that hard to parse, honest! I'd far rather any effort on the API was put into adding functionality, for example, the persistent client identifier suggestion that I discussed with Ed when I visited back in May.
  • Doug - K3TZR
    Doug - K3TZR Member
    edited October 2018
    Thanks to everyone for their comments.

    Here's a simple example:

    interlock tx1_delay=<value>

    vs

    cw break_in_delay <value>

    Both are in the form <command> <param> <value> but one use "=" and the other uses " " to separate the <param> from the <value>.

    Small difference but it makes the code to format commands dependent on specific knowledge of each command rather than knowledge of the pattern followed by all commands.

  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited July 2017
    Yep, totally agree that this is inconsistent.  I've entered an issue (#5040) in our tracker to look into changing this.  Thanks!
  • Doug - K3TZR
    Doug - K3TZR Member
    edited July 2017
    Thanks Steve

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.