Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Reduce development overhead by supporting only extended responses in Hamlib daemons in newly introduced commands

Aperta
  • Qualcosa non va?
#2,006 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 14 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
c
Ambito
backend-api-design

Direzione di ricerca

The proposal covers new commands in rigctld, rotctld, and ampctld but names no source files or tests. Start by tracing how command registration and response formatting work in each daemon, then review existing daemon command tests. Done means newly added commands require the + prefix for extended responses while existing commands retain their current behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Question

All Hamlib daemons (rigctld, rotctld and ampctld) support two types of responses for most commands (though even this is not 100% consistent, see below).

Proposal

I propose we stop supporting the non-extended responses in all new commands added to any Hamlib daemon. The existing commands would still work as expected (current API won't be broken), but new commands would require use of + prefix to work.

The non-extended response format introduces considerable burden on maintenance and development (we'd have to support two different kinds of responses) with little to no gain: the non-extended responses are rather difficult to handle predictably by clients reading the TCP stream. See below for a more detailed analysis.

New behavior

Hamlib daemons handle unknown commands in a rather "passive" way, by simply not returning any response (which itself is bad, but we can't really fix it right now without breaking the daemon command API), so with any new commands not supporting non-extended responses, the command would be silently ignored.

Examples:

No response to a new command that doesn't support non-extended responses:

\new_command

Extended response with a new command:

+\new_command
new_command:
Response: 1
RPRT 0

Non-extended response format and its drawbacks

The non-extended response is usually (but not always!) a one-line response with no indication of field names or any metadata. The command may be a short form (single char) or long form command (starting with a backslash \), e.g.:

f
145000000

\get_freq
145000000

However, there are exceptions to the single-line approach, such as...

Multi-line responses:

\get_split_freq_mode
0

0

Caps dump returning extended response always: (Would likely be impossible to parse otherwise)

1
Caps dump for model: 1
Model name:	Dummy
Mfg name:	Hamlib
...
RPRT 0

As we can see, the challenge with this format is that it's not consistent and it's difficult to parse:

  • Critical flaw: Client parser needs to know exactly what to expect in the response, since there is no indication of where the response ends -> With a TCP connection, there has to be some framing present to know where response ends.
  • More complex responses, ones with several or tens of fields, become difficult to represent and to parse
  • The response format is difficult to extend, as there is no indication of what values represent what information -> clients will be easily confused even if new fields are added in the response
  • Even right now, responses are not consistent: single-line and multi-line responses are mixed + caps dump returning extended responses always.

Extended responses

The extended response mode is enabled with a plus char +, leading to a more structured response format, including an indicator for the end of the response (RPRT [CODE]). Both of these features make usage of extended responses basically a must in TCP clients.

Here is a good example of how the extended response makes parsing the responses easy.

Non-extended response with no indication of where the response ends or the meaning of the values returned:

\get_vfo_info VFOA
145000000
FM
15000
0
0

Extended response with repeated command on the first line, response as key-value pairs and RPRT 0 ending the response.

+\get_vfo_info VFOA
get_vfo_info: VFOA
Freq: 145000000
Mode: FM
Width: 15000
Split: 0
SatMode: 0
RPRT 0
Lingua principale
C
Stelle
851
Fork
308
Merge medio
13g 19h
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Hamlib/Hamlib

Tutte le issue di Hamlib/Hamlib

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.