Zukunft mit IPS

Erweiterungen PHP-Module (Entwicklung)
1

Hi Entwicklergemeinde…

Ich steh ja so ein bisschen auf Kriegsfuß mit der SDK-Modul-Politik und dem ewigen Problem „Verfallsdatum Unbekannt“. Klar haben Anwender keinen Bock drauf sich mit nem vorschnellen Update das System lahm zu legen. Kann ich auch verstehen. Und ich hab ständig extra Arbeit davon.

Für das Latitude-Problem würde ich denn auch gern mal was Neues probieren. Die Frage ist nur wohin geht die Reise?

Die SOAP-Schnittstelle kenne ich ja schon. Sie ist zwar auch etwas tricky aber läuft eigentlich seit Anfang an gleichbleibend stabil. Ein absolutes Plus ist die Message-Sink da auf diese Weise eine BiDi-Verbindung zu einer externen Applikation möglich ist. Grad hab ich ein bisschen mit JSON herum gespielt. Gibts da auch sowas? Oder ist das der Engpass in dieser Technik?

Was mich natürlich interessiert:

[ul]
[li]Werden zukünftig beide Techniken unterstützt oder wohin geht die Reise?
[/li][li]RPC ist ja klassisch nur für Prozeduraufrufe. Kann ich dort interne Messages abonieren wie unter SOAP?
[/li][li]Wenn nicht, wäre die SOAP-Schnittstelle ja doch um einiges mächtiger. Wie sicher ist es diesen Weg weiter zu beschreiten.
[/li][li]Gibt es weitere Dinge, die man mit einer der Techniken auch zukünftig nicht tun können wird und worin liegt der Vorteil von JSON mal abgesehen von der Geschwindigkeit?
[/li][/ul]

Gruß,

Toni

2

Hallo Toni,

so sehr ich dir Antworten auf deine Fragen geben möchte, umso mehr will ich dir eine Gegenfrage stellen:

Warum willst du dir das Leben jedes Mal so kompliziert machen und immer externe Tools schreiben, die du persönlich immer warten musst, weil keiner den Quellcode hat? Soweit ich das auf die schnelle sehe ist die Latitude Sache komplett in PHP geschrieben. (20 Zeilen Quellcode) Es gibt damit niemals Update Probleme seitens IPS und das aktuelle hat Google verursacht. Dafür aktualisierst du, oder irgendwer das Skript und es läuft wieder. Das selbe ist hier mit zig Skripten im Forum passiert. Wenn ein alter User nicht mehr Lust hatte sich weiter darum zu kümmern, so konnte jemand anderes dort weitermachen, wo der letzte aufgehört hat.

Deine Frage wirkt leider so, als wenn du wieder anfangen willst, extra Tools zu bauen.

Mein Rat an dich: Nutz alle Möglichkeiten die PHP und die IP-Symcon Befehlsreferenz/Modulreferenz hat. Damit fährst du nachhaltig am aller sichersten, und erspart dir jeglichen Ärger. Nutz doch z.B. einfach eine HTMLBox. Die ist sieht im WF gut aus und du hast fast alle Freiheiten. Außerdem integriert es sich nahtlos in IP-Symcon.

paresy

3

Das kann ich dir genau verraten. Es gibt direkt mehrere Gründe. Einmal weil man speziell für die Latitude-Geschichte jetzt etwas mehr braucht als ein paar Zeilen PHP (z.B. verschachtelte Web-Requests, Authentifizierung, SSL, OAuth). Ausserdem weil ich nicht viel PHP beherrsche (reicht für den Hausgebrauch) und es ausserhalb von IPS auch nicht brauche. Und zu guter Letzt suche ich immer noch eine Generallösung für alle anstehenden Aufgaben. Beispielsweise die SMSWitch durch eine Reihe von Scripten zu ersetzen ist schlicht tierisch aufwändig und unübersichtlich. Ich hasse es auch wenn ich irgendwann zur Bewältigung einer einzigen Aufgabe 7 Scripte und 12 Includes zusammen mit ner manuell eingebundenen PHP-Extension brauche. Am besten noch verschiedene Aufgaben mit einem Netz von Abhängigkeiten erzeuge.

Oder ein anderes Beispiel. Der OpenHardwareMonitor ist eine externe Software, die über WMI mit IPS kommuniziert. Dafür muss sie im selben userbezogenen Kontext erreichbar sein. Zimlich simpel (für mich) das in Delphi umzusetzen. Aber gerade das starten und killen des Prozesses innerhalb des Systemkontos ist eben nicht mit ein paar Zeilen PHP gemacht. Zumal nur Murks bei rum kommt wenn nach einem Neustart von IPS der Prozess mehrmals läuft.

Ich hab auch einen fast fertigen komfortablen DLNA Controlpoint mit allem Schick-Micki oder einen funktionierenden OPC-Client auf der Platte. Habs nicht (wirklich) publik gemacht weil das Thema so komplex ist, dass ich nicht weiss wieviel Arbeit auf mich zu kommt wenn „ständig“ die Kompatibilität in Frage gestellt wird und ich mich zu einem mir vorher unbekannten Zeitpunkt kurzfristig in teils längst vergessene Internas rein denken muss.

Das Latitude-Problem ist, aus aktuellem Anlass, also nur Stellvertreter für ein Problem, dass ich seit IPS 2.0 ungelöst sehe.

Ich würde gerne für mich selbst unabhängig werden von dem Updatezyklus von IPS. Gerne teile ich meine Arbeit kostenlos mit Anderen und unterstütze die Community. Aber das ist gar nicht so einfach. :frowning:

Könnte ich also statt eines Moduls einen völlig unabhängigen Dienst anbieten, der nahtlos mit IPS interagiert, so wären wir (ich) ganz weit vorne. Wenn ich mich dann noch um Plattformunabhängikeit kümmere, was dann allein in meinem Ermessen läge, wäre das ein weiterer Schritt (über SOAP oder JSON kann ich ja auch von ner Linux-Maschine oder Sat-Receiver kommunizieren). Dann wären auch so dumme Versionskonflikte wie sie zwischen BDS2006 und dem RAD Studio 2009, das ich benutze, bekannt sind vollkommen egal.

4

Das ist leider der Trade-Off den du machen musst. Die PHP Anbindung ist unter Umständen (für dich) komplizierter in der Erstumsetzung, hat aber viele Vorteile, die meiner Meinung nach langfristig die Wartung erleichtern.

  • WMI geht z.B. über die COM PHP Extension, die PHP mitliefert und über das LiveUpdate aktualisiert wird.
  • SMSWitch sehe ich als Ausnahme - Das Thema ist in der Tat komplex, wobei auch da seit der 2.7 eine bessere Integration über die PropertyPages (siehe forms-Ordner) möglich ist.
  • Für OAuth gibt es unter PHP Bibliotheken. Für die Token-Authentifizierung kann man kurz in den Browser wechseln. So machen es auch alle mobilen Apps. Das ist dem Benutzer zuzutrauen.

Ich sehe hier einfach deinen Fokus auf Delphi, den du gerne erhalten willst.

Zu deinen JSON-RPC Fragen:

a) SOAP werde ich vermutlich in der 3.1/3.2 per Default deaktivieren. Es bleibt aber manuell für jeden Nutzer reaktivierbar. Es gibt keinen Grund die SOAP-Schnittstelle komplett zu entfernen.
b) Ja, das geht. Da ich mir dort aber Änderungen vor behalte, gibt es das nicht offiziell. Und mit deiner Einstellung zur Thematik, willst du die aktuelle Methode dann wahrscheinlich auch nicht Wissen :wink:
c) Ich sehe für SMSWitch oder Latitude keinerlei Notwendigkeit irgendwelche Nachrichten zu abonnieren.
d) JSON-RPC ist schneller, auch für einen Laien zu verstehen, zu 100% mit der Befehls- und Modulreferenz kompatibel und es bietet einen Benutzernamen/Kennwortschutz. SOAP kann als einzigen Vorteil die WSDL verbuchen, die aber im Prinzip auch nur versierte Programmierer ausnutzen können. Außerdem muss du wegen der Modularisierung einiges über die IPS-Interna wissen.

Irgendwann wird SOAP wegfallen. Solange es dazu aber keinen triftigen Grund gibt, wird es das nicht. Im Zweifelsfall kann man dann ja immer noch einen JSON-RPC <> SOAP Proxy anbieten, wenn die Nachfrage vorhanden sein sollten.

Falls du zu 100% komplett auf der sicheren Seite sein willst, schau dir die IPSTools an. Die nutzen den ClientSocket zur BiDi-Kommunikation. http://www.ip-symcon.de/wiki/IPSTools

Mit der JSON-RPC Schnittstelle setzt du aber auf längere Sicht aufs gute Pferd, da wir diese Schnittstelle intern für das WebFront nutzen, bald komplett die mobilen Apps darauf umstellen und die Konsole hoffentlich zur 3.1 auch darauf umgestellt sein wird.

paresy

PS: Für Delphi habe ich vielleicht demnächst einen JSON-RPC Wrapper der automatisch alle Funktionen generiert :wink:

5

Versteh mich nicht falsch. Ich möchte nicht versuchen dich dazu zu bewegen irgend einen Kurs einzuschlagen sondern nur versuchen für mich den Weg des geringsten Wiederstandes zu finden. Durch das SOAP-Gewusel musste ich mich schon durchwühlen und hab funktionierende Konzepte für mich gefunden. In TRIXI zum Beispiel steckt nicht mehr viel vom IPS-SDK. Das läuft relativ nativ und sehr stabil auch unter Delphi 2009 und 2010, dass ja selbst nicht fürs SDK freigegeben ist.

Die Lösung der IPSTools finde ich am geschmeidigsten. Jahre vor Brownson hab ich das ja schon in den ToniTools so gemacht. Aber bei der Geschichte mit den bidirektionalen Telegrammen gab es immer wieder Schwierigkeiten mit der Latenz (Netzwerkseitig, nicht auf IPS bezogen) und ich hab ständig nur den Leuten erklärt wie sie ihre Firewall anpassen/abschalten, etc.

Wir hatten ja vor langer Zeit schon mal PHP-Module, die wir damals Bricks genannt haben. Der große Vorteil war dass man eben nicht an zig stellen im System Codeschnipsel auffinden und aufrufen musste. Auch das PHP-Monster von Brownson ist mir von der Sache her zuwieder. Ne Hand voll Leute können es bedienen und noch weniger blicken wirklich was da läuft und könnten Fehler finden oder ne zerschossene Installation reparieren.

Ich sehe hier einfach deinen Fokus auf Delphi, den du gerne erhalten willst.

Letztlich ist es, auf professioneller Ebene betrachtet, vollkommen egal in welcher Programmiersprache etwas verfasst ist solange nur die Schnittstelle definiert und dokumentiert ist. Wie du sicher weisst ist Delphi mittlerweile schon fast ein Exot. Ich verwende beruflich täglich Schnittstellen für die es keine Delphi-SDK gibt. Ich hab überhaupt keine Schmerzen damit mir clientseitig etwas Eigenes auszudenken und wochenlang Grundlagen zu implementieren. Nur wüsste ich gern welche Halbwertzeit diese Arbeit hat.

Ich muss dir im Idealfall ja auch gar nicht erzählen in welcher Sprache ich deine Schnittstelle verwende. Solange nur die Inputs und Outputs definiert sind und sich nicht ständig ändern. Mein Lieblingsbeispiel ist Winamp. Es ist in keiner Weise für Delphi ausgelegt. Aber man kann, mit dem richtigen Backgroundwissen prima Plugins dafür schreiben. In jeder beliebigen Sprache. Und das seit (Software-)Generationen.

Ich sehe für SMSWitch […] keinerlei Notwendigkeit irgendwelche Nachrichten zu abonnieren.

Aber das Senden und Empfangen von SMS auf einer „unidirektionalen Datenleitung“ ist schon ne Kunst :wink:

JSON-RPC ist schneller, auch für einen Laien zu verstehen

Meine „Zielgruppe“ war bisher immer der User, der nicht mal das versteht. Und diesen User würde ich gern auch zukünftig im Auge behalten.

Für OAuth gibt es unter PHP Bibliotheken[…]

Die dieser Benutzer vermutlich erst mal im Netz in der richtigen Version finden und in IPS eingebunden bekommen muss. Nach einem IPS-Update mit neuer PHP-Version funktioniert sie dann u.U. nicht mehr. Das find ich ehrlich gesagt doof.

6

Hallo Toni,

ich habe bei IPSView auf Json gesetzt.
Erstens gibt es für die meisten Sprachen bereits Wrapper und zweitens ist es auch ein sehr kompaktes Format. Da bereits jetzt, einige IPS Komponenten in diesem Format miteinander kommunizieren, kann man davon ausgehen, dass dieses Format in IP-Symcon Zukunft hat.
Bei IPSView hab ich mir noch ein kleines PHP - Skript dazwischengehängt, das sorgt nochmals dafür, dass ich unabhängiger bin.
Auch die Socket Kommunikation von den IPSTools hat sich bewährt, hat seit der Erstellung im wesentlichen keine Wartung benötigt - hatte bereits fast vergessen, dass das Ding auch bei mir herumwerkelt.

Was die IPSLibrary betrifft, so erfordert die durchaus eine gewisse Einarbeitungszeit - für mich hat sich der ModuleManager aber bereits mehrfach bewährt.
Einerseits konnte ich damit den nötigen Support etwas senken und andererseits kann ich auch nötige Updates innerhalb von Minuten in die Community ausrollen.
Vorteil von GIT ist auch, dass man da auch gleich ein volles Versionskontrollsystem mit dabei hat.

7

So gings mir mit SOAP. SOAP war toll. SOAP die Zukunft. IPS benutzt intern selbst SOAP. Bloß nix anderes mehr als SOAP machen. Zukünftig wird SOAP wohl per default deaktiviert sein. :rolleyes:

Ich meine die Technik ist schnellebig und Software teils noch mehr. Das ist mein täglich Brot und ich bin daran gewöhnt. Ich bekomme mein Gehalt und man bezahlt meiner Rechnungen und ich lasse „mein Kind“ ziehen. Hier liegt die Sachlage faktisch anders. Ich kann nicht ziehen lassen weil ständig nachgebessert und geupdatet werden muss und es geht um meine Freizeit.

Zwei Lösungen schweben mir momentan vor. Entweder ich finde einen Weg den User weiterhin ohne jegliche Vorkenntnis zu erreichen und alles mit ein, zwei Klicks zur verfügung zu stellen oder ich trenne mich von IPS und stelle eine einfache Schnittstelle bereit, für die sich versierte User dann selbst Scripte ausdenken und pflegen dürfen.

Edit:

Ich trenne mich natürlich nicht von IPS sondern vom SDK :rolleyes:

8

Mit dem SDK ist es möglich, hardwarenahe Protokolle zu implementieren, was mit einem Query/Response-Modell wie mit Json nicht möglich ist. Ich kann nicht im Millisekunden-Bereich die JSON API-Pollen, um die Antwort von meiner Hardware zu bekommen, vom CPU-Verbrauch abgesehen. Dafür gibt es halt asyncrone Messages und ggfls CallBacks.
Ich würde mir aber auch eine mehr versionsunabhängige Variante des SDK in Form einer DLL u.ä. wünschen, die man ganz klassisch mit dem Tool seiner Wahl ansprechen kann und wo die enthaltenen Funktionen wie bei anderen DLLs auch über mehrere Versionen genauso funktionieren.

Tommi