Lorawan-stack: Unterstützung benutzerdefinierter Variablen in Webhook-URLs

Basierend auf dem Aussehen der Felder vermute ich, dass Sie dies mit text/template implementieren wollten. Wenn dies tatsächlich der Fall ist, beachten Sie bitte, dass das Parsen und Ausführen von Vorlagen (insbesondere wenn es sich nicht nur um die Basis-URL, sondern auch um den Pfad handelt) auf jedem Uplink möglicherweise sehr ressourcenintensiv sein kann.
Stellen Sie außerdem sicher, dass Sie eine sehr eingeschränkte Struktur verwenden, mit der die Vorlage ausgeführt wird. Verwenden Sie nur primitive Typen (wandeln Sie also alle EUIs/DevAddr in Zeichenfolgen um), vermeiden Sie Zeiger.

Ich denke, wir können die Vorlage selbst mit der Webhook-ID + updated_at , um zu vermeiden, dass die Vorlage jedes Mal neu kompiliert wird. Außerdem ist es in der Tat so, dass nur Strings an das Template selbst übergeben werden sollten (und ich würde es vorziehen, dass wir nichts anderes außer den Bezeichnern verwenden).

Ich denke, zwei Möglichkeiten;

• Verwenden Sie text/template mit einer sehr einfachen Struktur, die für diesen Anwendungsfall spezifisch ist. Das heißt, geben Sie nicht *ttnpb.ApplicationUp sondern WebhookTemplateFields nur mit dem Zeug weiter, das wir unterstützen
• Verwenden Sie Zeichenfolgenersetzung für die bekannten Felder. Super schnell, gleiches Ergebnis

Wenn wir uns für die zweite entscheiden, sollten wir wahrscheinlich überhaupt nicht die Go-Template-Syntax verwenden, da dies die Leute nur verwirren würde (warum der Punkt? ist er mit Leerzeichen aufgefüllt?).

Wenn wir die Validierungsregeln gleich halten wollen, könnten wir die Verwendung von Platzhaltern wie $app_id in Betracht ziehen. Auf diese Weise sind die Platzhalter im Host nicht gültig (weil wir das nicht wollen), aber im Pfad (ich denke, $ ist in URL-Pfaden erlaubt, das müssen wir überprüfen ).

$ ist sowohl als Teil des Hosts als auch als Pfad gemäß RFC3986 Abschnitt 2.2 gültig. Abgesehen davon sind wir nicht gezwungen, den Host-Teil von url.URL zu parsen.

Die Standardsyntax (gemäß RFC 6570 , siehe 1.2 und 2.2) für URI-Vorlagen ist {[operator]variable-list} . Da wir an einem Hotspot arbeiten, glaube ich, dass dies eine gute Begründung dafür ist, die Operatoren fallen zu lassen (da sie eine längere Verarbeitung erfordern würden) und nur eine Variable zuzulassen. Dadurch können wir string.ReplaceAll verwenden, ohne das Rad neu erfinden zu müssen.

Was meinst du mit "eine Variable zulassen"?

Ich denke auch, dass es in Bezug auf die Benutzererfahrung schöner ist, text/template nicht zu verwenden, abgesehen von der Leistungseinbuße. Mir geht es gut mit Variablennamen im PHP-Stil.

Der oben erwähnte Standard würde Ausdrücke wie {appEUI,devEUI} zulassen, was es uns nicht erlauben würde, den einfachen String-Ersatz zu verwenden. Beachten Sie, dass ich Ausdrücke wie {appEUI}/{devEUI} nicht verboten habe, die nur eine Variable pro Erfassung haben und vollkommen in Ordnung sind.

Wie wäre es mit diesem?

Dieses ist ein internes Paket und kann nicht außerhalb des Hauptpakets importiert werden, aber dies sollte es tun.
Bearbeiten: Das Hauptpaket macht die Funktion ebenfalls verfügbar.