Références : https://github.com/TheThingsNetwork/lorawan-stack/issues/2047
Les valeurs renvoyées par NS pour les énumérations dans le champ mac_settings
sont incohérentes. Certains pour certains NS renvoient des valeurs brutes et pour d'autres une représentation sous forme de chaîne est renvoyée.
mac_settings.rx1_delay.value
// request
{
"end_device":{
"mac_settings":{
"rx1_delay":{
"value":5 // or 'RX_DELAY_5'
}
}
},
"field_mask":{
"paths":[
"mac_settings.rx1_delay.value",
]
}
}
// response
{
...
"mac_settings":{
"rx1_delay":{
"value":5
},
}
}
// Note, regardless of what you send as the value for mac_settings.rx1_delay.value you always get the raw enum value.
mac_settings.ping_slot_periodicity.value
// request
{
"end_device":{
"mac_settings":{
"ping_slot_periodicity":{
"value": 1 // or 'PING_EVERY_2S'
}
}
},
"field_mask":{
"paths":[
"mac_settings.ping_slot_periodicity.value"
]
}
}
// response
{
"mac_settings":{
"ping_slot_periodicity":{
"value":"PING_EVERY_2S"
}
}
}
// Again, regardless of what you send you always get the string representation of the value.
Valeurs incohérentes pour les champs d'énumération mac_settings
Toutes les valeurs doivent être renvoyées dans le même format (brut/chaîne)
v3.7.0-rc2
Je suppose que nous devons d'abord nous mettre d'accord sur le format. Ensuite, il s'agit d'ajuster https://github.com/TheThingsNetwork/lorawan-stack/blob/master/api/lorawan.proto et https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg /ttnpb/lorawan.go
Oui, mais besoin de la contribution de @rvolosatovs @johanstokking @htdvisser
Quelle contribution est requise de notre part ( @rvolosatovs @johanstokking @htdvisser) ? Ce problème manque-t-il une étiquette discussion
?
FTR, je pense que cela dépend des champs dont nous parlons, mais pour les éléments MAC spécifiques à LoRaWAN, je pense que nous devrions utiliser uniquement le nombre, car cela correspond à la spécification (la périodicité de l'emplacement Ping de PING_EVERY_2S
n'est pas défini dans la spécification, mais celui de 1
l'est)
Ce n'est malheureusement pas quelque chose que nous pouvons simplement changer, car cela violerait notre engagement de compatibilité API, donc ce n'est certainement pas quelque chose pour mars.
Il existe actuellement en effet plusieurs façons de rendre une énumération. Par exemple, MACVersion
peut être rendu comme "MAC_V1_0_2"
, 3
(tous deux conformes à jsonpb) ou comme "1.0.2"
(avec le stringer de TTN, non conforme). Dans le passé, nous avons commis l'erreur d'utiliser le troisième ( "1.0.2"
) lors du rendu JSON. Nous n'aurions pas dû faire cela, mais nous ne pouvons plus changer cela sans casser notre API.
Afin d'être aussi compatibles que possible, nous acceptons tous les formulaires dans les messages de demande, mais ce que nous renvoyons ne peut plus être facilement modifié.
À l'avenir (avec l'API goproto v2), nous pourrions peut-être ajouter la prise en charge d'une extension dans l'en-tête Accept
, de la même manière que Github le fait. Cette extension pourrait alors être utilisée pour indiquer au serveur comment les énumérations (et par exemple les champs zéro) doivent être rendues.
fermé car nous ne résoudrons pas ce problème
Je ne pense pas que nous devrions immédiatement rejeter cela comme une habitude. Gardons-le dans l'arriéré et voyons si nous pouvons y remédier à l'avenir.
Excellent pour V4
Commentaire le plus utile
Excellent pour V4