Da wir langsam den Changelog für den RC1 vorbereiten, wollte ich die Informationen zu IPSModuleStrict nicht verlieren und diese in einem frischen Thema ablegen. Wir haben uns außerdem entschlossen IPSModuleStrict in der 7.0 noch als „Preview“ zu betiteln, da es noch nicht alle von uns gewünschten Funktionen enthält. Wir werden zur 7.1 daran weiter arbeiten.
Hier noch unser Video, in dem wir auf die Hintergründe eingehen und auch unsere Wünsche für IPSModuleStrict:
Hinweise zur neuen PHP Version - insbesondere für Modul-Entwickler:
Aktuell läuft PHP 8.2 mit dem Error-Reporting auf „E_ALL ^ E_DEPRECATED“. D.h. wir haben alle Deprecations deaktiviert, um Zeit für notwendige Änderungen zu erlauben. Insbesondere sind utf8_encode und utf8_decode als Deprecated markiert, sodass die Deprecation Warnings aktuell noch viel Ärger bereiten würden.
Unsere Migrationsstrategie ist wie folgt:
IP-Symcon 7.0 lässt die Deprecations aus und bietet zeitnah eine neue IPSModuleStrict Klasse an, welche TypeHints bei den Klassen-Funktionen besitzt, Variablen als ReadOnly markiert ($this->SetValue muss dann genutzt werden) und welche im Datenfluss die Daten nicht mehr per „utf8_encode“ kodiert, sondern binäre Daten als HEX kodiert überträgt. Dies bedeutet, dass ein Buffer vom ClientSocket nicht mehr per utf8_decode, sondern per hex2bin verarbeitet werdet muss. Da fürs erste die IPSModule Klasse unangefasst bleibt - können wir in Ruhe umstellen.
IP-Symcon 7.x: Sobald eine kritische Masse an Modulen umgestellt wurde (wir können über den Module Store ja passende Statistiken erstellen) würden wir die Deprecations reaktivieren, um dadurch den Rest an Kleinigkeiten zu finden, sodass wir langfristig auf PHP 9.0 vorbereitet sind. Ende des Jahres kommt ja erstmal PHP 8.3.
Hinweise zu IPSModuleStrict:
Da TypeHints definiert sind, sind auch diese für eure Klassen notwendig. Ich werde versuchen dafür ein Skript oder ähnliches zu schreiben, welches diese Fleißarbeit automatisiert.
Alle bisherigen Warnings sind nun Fehler. z.B. wenn keine TypeHints bei Public Funktionen definiert sind oder wenn ihr als TypeHint die veralteten Integer/Boolean TypeHint nutzt.
Bisher gab es keinen TypeHint für Variant. Dafür könnt ihr (seit PHP 8.0 verfügbar) mixed nutzen.
RegisterVariabe* liefert einen Boolean, ob die Variable erstellt wurde (bisher wurde die ID der Variable zurückgeliefert. Diese könnt ihr jederzeit über $this->GetIDForIdent beziehen)
Die erstellten Variablen sind ab sofort ReadOnly. D.h. ihr müsst $this->SetValue nutzen, um diese zu beschreiben
Der Datenfluss überträgt alle binären Daten als HEX-Kodiert. D.h. ihr müsst nicht mehr utf8_encode/utf8_decode nutzen, sondern bin2hex und hex2bin bei allen unseren nativen Instanzen. Für eure Modul könnt ihr weiterhin frei wählen aber generell ist utf8_encode/utf8_decode deprecated und sollte nirgends mehr genutzt werden
Könnt ihr kurz erläutern, wie der Stand zu diesem Thema ist?
Ich habe angefangen, die ersten Module auf IPSModuleStrict umzubauen. Aber jetzt wurde das erste Modul beim Review abgelehnt mit dem Hinweis, dass erst das Handling für physikalisch übergeordnete Objekte seitens Symcon noch umgebaut werden soll.
Gibt es dazu schon einen Zeitplan? Momentan bin ich wohl in einer Sackgasse
Gibt es hier inzwischen etwas Neues? Ich würde gerne an dem Umbau weiterarbeiten, aber momentan weiß ich nicht, wie es mit IPSModuleStrict weitergehen wird.
Kurzer Abriss über das geplante Konzept bzgl. Datenflussverbindungen:
Langfristig wird die Konsole jegliche Erstellung der Instanzen übernehmen. Das bedeutet, dass es kein RequireParent/ConnectParent/ForceParent mehr geben wird. (Und auch nicht geben muss in diesem Sinn). Der Vorteil: Es wird immer genau die Instanz erstellt, die am sinnvollsten ist und die der Kunde nach euren Vorgaben ausgewählt hat. Abweichende Ketten in Konfiguratoren bekämpfen dann auch nicht mehr die internen RequireParent/ConnectParent/ForceParent Funktionen.
Wir wollen dies umsetzen, indem wir die RequireParent/ConnectParent/ForceParent Funktionen entfernen und dafür eine neue GetCompatibleParents() Callback Funktion anbieten für IPSModuleStrict. Für IPSModule bleibt alles gleich. Langfristig werden die RequireParent/ConnectParent/ForceParent in IPSModule nichts mehr machen und nur die GetCompatibleParents() mit den notwendigen Informationen befüllen. Das sollte für fast alle alten Module abwärtskompatibel bleiben.
Diese Callback Funktion liefert ähnliche Informationen zurück:
{
'type' : 'connect ODER require',
'moduleIDs': ['GUID1', 'GUID2'],
}
Der Vorteil: Ihr gebt weiterhin vor, was eure Empfehlung ist - die Konsole bzw. der Kunde kann aber entscheiden, welche der Empfehlungen er folgt. Beispiel: Aktuell ist es immer doof neue ModBus Geräte zu erstellen, die an einen neuen ModBus (TCP/RTU) Splitter sollen. Die Konsole vertraut auf das ConnectParent und das hängt sich an irgendeinen vorhandenen ModBus Splitter ran. Der Experte weiß, dass er dann „Gateway ändern“ klicken muss. In Zukunft wird die Konsole fragen (wenn nicht die erste Instanz erstellt wird), ob die Instanz sich an einen vorhandenen Splitter hängen soll oder ein neuer erstellt werden soll.
In den meisten Fällen braucht ihr GetCompatibleParents() gar nicht mehr. Denn: Es hat sich herauskristallisiert, dass in den meisten fällen folgendes zutrifft:
a) Für Splitter, Discovery, Konfigurator:
c) Für alles andere einfach {}, da es keinerlei relevanten Datenfluss dafür gibt.
D.h. der Datenfluss (PR/CR/I) definiert fast von alleine die relevanten Bedingungen. Und für die restlichen Fälle (meistens das ForceParent/RequireParent in Splittern) würdet ihr die Empfehlung vorgeben. Sollte also ein ‚require‘ mit exakt einer ModuleID zurückgegeben werden, die nicht der aktuellen entspricht, würde die Konsole den Nutzer auffordern die übergeordneten Instanzen zu ersetzen/korrigieren. Trotzdem mit der Hoheit des Nutzer, aber mit der dringenden notwendigen Aufforderungen.
Für den Übergang - also die Zeit, in der die Konsole das volle neue Featureset nicht unterstützt - wird GetCompatibleParents() trotzdem intern die bekannten RequireParent/ConnectParent/ForceParent Funktionen aufrufen, sodass sich für euch eigentlich nichts ändert - außer, dass ihr in 90% der Fälle RequireParent/ConnectParent/ForceParent entfernen könnt und in den wenigen Restfällen die neue GetCompatibleParents() Funktion definierten müsst.
Sobald das neue Feature in IPSModuleStrict landet, werden die RequireParent/ConnectParent/ForceParent Funktionen erstmal nur „tot“ geschaltet, sodass wir einen etwas sanfteren Übergang haben. Die Module müssten dann aber entsprechend angepasst werden, da wir Richtung RC1 die RequireParent/ConnectParent/ForceParent Funktionen aus IPSModuleStrict entfernen möchten.
Viel Text, aber ich hoffe, dass dies unser neues Konzept verdeutlicht
