Nut upsdev - Apr 2023 - Considering extensions to socket protocol (driver-to-upsd)

Hello all,

  As one outcome of my recent burst of activity, I found what I think is a
deficiency in NUT socket protocol, logged at
https://github.com/networkupstools/nut/issues/1920 now.

Relevant extract:

*Currently dstate::sock_arg() in many cases quietly does:*

*/* The command was handled, status is a separate consideration */
return 1;
*

*Which does not tell the direct client (upsd) or eventually the user's
client (upscmd, upsrw...) how that handling ended up.*

*At least some (new) cases might instantly report whether they succeeded or
not, similar to how DATADUMP handling ends with DATAOK (as opposed to
DATASTALE), or PING ends with PONG, but currently do not due to lack of
protocol keywords for that at the moment.*

*The return values from main/driver-specific handlers (per enums in
drivers/upshandler.h) might be reported in a similar fashion at least on
the socket protocol. Just to know the command was acknowledged and perhaps
how it ended up.*

*In the bigger picture, may the socket protocol be treated as a private
experience between current versions of upsd and NUT drivers - e.g. if
someone built/scripted interactions around that, and those third-party
tools fail due to unexpected key words, we commiserate but it is not a NUT
problem as such?*

*To be clearer, this is not immediately a question about on-line NUT
protocol (data server to clients), although I would not be surprised if it
sprouts into that too (or practical handling of that, to more relevantly
report OK/ERR for client requests).*

What would the esteemed community suggest here (especially if there are
some impacts I might have overseen in the cursory reading?)

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230421/75969a15/attachment.htm>