[Ovmsdev] Addition to OVMS Developer Guide

[Michael Balzer]

Steve,

Am 01.01.21 um 02:34 schrieb Stephen Casner:
>> Regarding command options: for my latest command addition (obdii requests) I
>> checked if we can use getopt_r(). Problems are a) it's not in the newlib
>> included in esp-idf, and b) we also would need to change all handler
>> signatures to allow getopt to modify the argv array. I also checked if some
>> clever C++ getopt class is available but found none.
> Another option (pun intended) would be to stick more with the original
> parser design with trailing positional optional parameters rather than
> prefix option flags.  Option flags are familiar to many of us
> developers, but that might not be the best choice for implementation
> here.

Positional optional parameters don't grow well for multiple options, 
force users to a fixed argument scheme and tend to produce hardly 
readable commands. I also think command options are for 
experienced/advanced users, and those are familiar with the concept.

Extending the parser to support command argument templates would be an 
option, but I had the impression that would add a lot of complexity, and 
would only benefit a small set of (advanced) commands. (Side note: 
regarding command templates, I really liked the AmigaOS template scheme, 
IMO a shame it didn't get adopted more widely.)

> Now, I'll admit that the obdii command has complex options that may
> need to be implemented as you have done.  However, let me cite one
> counterexample:
>
> Usage: event raise [-d<delay_ms>] <event>
>
> This could have been done like homelink:
>
> Usage: homelink <homelink> [<duration=1000ms>]
>
> The latter form would be cleaner in that you wouldn't have to type the
> -d prefix.  Also, the tab completion that I implemented before you
> added the delay option is now broken, although it would not be hard to
> fix.

Agreed for the case of a single option and a command that's not supposed 
to grow any new features. I did so on some of the CANopen commands. But 
imagine we need to add another numerical option to "event raise": nice 
and clean by prefix options, a usability nightmare with positional args.

I wasn't aware of the tab completion on "event raise"… I normally use 
the command to raise custom events only. I'll fix that.

> With the flexibility to have intermediate parameters now, using the
> validate function, it may fit reasonably to have the options handled
> by a subtree.
>
>                                                          -- Steve

Do you mean a secondary option subtree triggered by the "-" prefix, 
inherited to the regular command subtree?

That would allow simple tab completion on options as well… sounds like a 
nice idea.

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210101/7e245de3/attachment.sig>