definierter Ort für Helperscripts

[ctr]

Derzeit haben wir einen "Wildwuchs" was den Speicherort von Helpern angeht, sowohl bei der Entwicklung als auch der CV Verzeichnisstruktur.

Beispiele:
rsslog-plugin - benötigt ein rsslog.php welches zusammen mit dem Plugin gespeichert wird (sowohl im GitHub als auch in der CV Verzeichnisstruktur)
wgplugin_info - benötigt ein script wg-plugindb.pl oder wg-plugindb.php welches hier https://github.com/OpenAutomationPro...ls/wg-plugindb gepflegt wird und vom Benutzer manuell in den webroot kopiert werden muss (Achtung: absoluter Pfad wird in CV benutzt um das Script zu finden)
GoogleCalenderHelper - kein eigenen Plugin sondern benutzt web-src, das nötige Helper-Script wird hier https://github.com/OpenAutomationPro...CalendarHelper gepflegt, es muss vom Benutzer manuell in ein zugreifbares Webverzeichnis kopiert werden und der Pfad entsprechend im Plugin genutzt werden

3 Scripts, drei verschiedene Repos und Wege es zu installieren, 3 verschiedene Speicherorte

"Eigentlich" mag ich die Variante vom rsslog-plugin, das benötigte Helperscript gleich im CV-Source zu haben. Das löst mehrere Probleme (z.B. keine manuelle Installations durch Nutzer nötig, relative Pfade möglich, damit "Reverse-Proxy freundlich"), allerdings gibt es ja noch helper scripts die nicht direkt an einem Plugin hängen.

Mein Vorschlag wäre es, mal einen Speicherort (sowohl in der Entwicklung als auch in der CV-Verzeichnisstruktur) als "Sollzustand" zu definieren und dann können wir nach und nach alles darauf anpassen.

(in beiden Optionen ist "/var/www/cometvisu" nur ein Beispiel für den Speicherort im Dateisystem)
Option 1) alle Helper Scripts sind zusammen mit dem zugehörigen Plugin zu speichern, also https://github.com/CometVisu/CometVisu/tree/develop/src/plugins/<plugin> und dann entsprechend /var/www/cometvisu/plugins/<plugin>
Frage: Wohin mit Helpern die nicht direkt an einem Plugin hängen, z.B. GoogleCalenderHelper
Option 2) alle Helper Scripts haben ihre Quellen außerhalb der CV (aber bitte generell entweder OpenAutomationProject/Wiregate _oder_ OpenAutomationProject/OpenAutomation) und werden in einem generischen Verzeichnis gespeichert, z.B. /var/www/cv-scripts, die CV sollte diese dann relativ ansprechen (z.B. ../cv-scripts/script.php)

In jedem Fall wäre es hilfreich, bei Plugins die ein Script nutzen, dass nicht mit der CV mitkommt den Pfad zu dem Script als Konfigurationsobjekt bei der Plugin-Nutzung abzufragen anstatt Pfade hart zu kodieren (Kandidat dafür wäre z.B. wgplugin_info)

Gedanke: Auch l,r,w könnte man evtl. in diese Überlegung einbeziehen, im Moment sind die ja auf /cgi-bin festgenagelt.


Wenn wir zu eine Konsens kommen würde ich das gern in Form von Pull Requests ändern.


Edit: Noch ein prominentes Beispiel (und damit auch schon der vierte unterschiedliche Fall) ist das diagram-plugin und rrdfetch, welches in /cgi-bin liegen muss und sogar als separates Paket daherkommt.

[Chris M.]

Grundsätzlich bin ich dabei, dass das einheitlich sein soll und am besten auch entsprechend gut beschrieben sein sollte, so dass neue Autoren wissen, was wo hin gehört (und Anwender erst recht...)
Aufpassen muss man jedoch, wofür eine Datei gebraucht wird - wenn es z.B. um ein WireGate-Plugin geht, dann sollte das nicht direkt in einem CometVisu-Plugin rum liegen. Hier bietet GitHub bessere Möglichkeiten (z.B. anderes Repository).

Dateien die an einem CometVisu-Plugin hängen, sollten IMHO in dem Verzeichnis für das Plugin liegen. Die Idee dahinter war/ist, dass man Plugins auch nachträglich leicht hinzufügen können möchte und dass am besten dadurch macht, dass man einfach ein Verzeichnis rein kopiert.
Jetzt ist das Problem daran aber, dass es Dateien gibt, die nicht zwingend im Web-Root hängen müssen/sollen aber evtl. wo anders wichtiger sind - wie z.B. cgi-bin Dateien.

Hier bin ich aktuell unsicher, wie das am besten zu lösen ist. Was meinen die anderen?

Und wie sollen wir hier zu einer Lösung kommen?
Jeden Fall einzeln durchspielen, bis wir ein Muster erkennen und das zur Regel erheben?

[ctr]

Gerade bei den ursprünglich Wiregate-lastigen CometVisu Plugins würde ich mir schon eine Entflechtung wünschen, damit die Plugins auch auf Nicht-Wiregates nutzbar sind. Korrigiere mich wenn ich falsch liege, aber es gibt doch nichts, was wirklich nur auf dem WG funktioniert. Selbst wgplugin_info ist ja nichts weiter als ein Wrapper für das Script, welches per Webcall Informationen aus einer DB holt. Eigentlich sollte es sinnvollerweise dbplugin_info heißen, dass die "db" dann einen bdb auf einem WG ist, abstrahiert das fetcher Script komplett.

Den Entwicklungstrang mal außen vor mein Vorschlag für das Filesystem Layout:
<cometvisu-root> wäre z.B. /var/www/cometvisu

• alle Plugin-spezifischen Scripts sind im Kontext des Plugins vorhanden
  • wie bereits bei rsslog.php, also <cometvisu-root>/plugins/rsslog/rsslog.php
  • rrdfetch könnte z.B. in den diagram-plugin context wandern, z.B. <cometvisu-root>/plugins/diagram/rrdfetch
• für widgets (z.B. wgplugin_info) und widget/plugin-unabhängige Scripts gibt es einen generischen Speicherort pro Applikation
  • <cometvisu-root>/scripts/wgplugin_info/wg-plugininfo.pl
  • <cometvisu-root>/scripts/GoogleCalendarHelper/GoogleCalendarHelper.php
• auch l,r,w könnte man dorthin umziehen, idealerweise mit einem "alternatives" (o.ä.) Ansatz um die eigentliche eibread/write-cgi (oder das entsprechende Backend) zu finden
  • <cometvisu-root>/scripts/backend/r -> /etc/alternatives/cv-backend-read

Baustellen damit das dann auch funktioniert:

• knxd, OpenHAB müsste sich mit "alternatives" (o.ä.) als Backend "registrieren"
• idealerweise sollten wir das wgplugin_info in dbplugin_info umbenennen, der Pfad zum Fetcher-Script sollte konfigurierbar gemacht werden
• klare Deklaration bei den Plugins, dass (welche) Scripts benutzt werden und welche Abhängigkeiten sie haben (wir haben inzwischen relativ viel perl und php, mind. php ist ja sowieso eine Abhängigkeit für die CV)

Damit wäre dann die CV im Prinzip "abgeschlossen" installierbar.

Für das linken in anderen GitHub Projekte kann man dann einzelne Projekte nach <cometvisu-root>/scripts verlinken.

[peuter]

Also für den von Dir als "alternatives" beschriebene Ansatz haben wir bereits eine Lösung in den neuen UniversalClient der CV eingebaut. Dadurch kann das Backend der CV mitteilen unter welchem Pfad l,r,w & rrdfetch zu finden sind. Dies könnte man ohne weiteres für andere Dinge mit nutzen.

Abgesehen von der bereits erwähnten Prämisse, dass Plugins alles was sie benötigen auch selbst mitbringen müssen (eine wie auch immer geartete Deklarations-Datei innerhalb der Plugins ist auch sinnvoll, denke ich), bin ich aber ebenfalls einigermaßen unentschlossen, was dieses Thema angeht.

Mal so grundsätzlich (ohne zu wissen ob das PHP-seitig brauchbar umsetzbar ist) würde ich mir einen zentralen Router vorstellen in den sich Plugins + Scripte rein registrieren können um diesem mitzuteilen: Wenn jemand einen Request an Pfad x/y/z schickt, dann reich mir den doch bitte durch und ich bearbeite den dann (Stichwort PSR7-middleware). Hätte den Vorteil, dass es aus CV-Sicht einen "root"-Pfad gibt unter dem alle Scripte/Plugins erreichbar sind, obwohl sie vielleicht tatsächlich irgendwo anders liegen auf dem Server. Alles was das CometVisu-Protokoll betrifft (also l,r,w) würde ich hiervon strikt trennen und keine Änderungen an der Stelle machen.