Sonderfaelle fuer update zulassen oder nicht

[rudolfkoenig]

Ich brauche noch weitere Meinungen, da ich unentschlossen bin.

Dirk will das HMCCU Modul von contrib nach FHEM bringen, was schonmal loeblich ist. Der Haken: HMCCU benoetigt zwei Dateien, die nicht ins normale FHEM-Modul-Schema passen: RPCQueue.pm und ccurpcd.pl

- RPCQueue.pm ist eine Bugfix-Version von File::Queue (eine "Persistent FIFO queue" Implementation). Wenn das nach FHEM kommt, dann muesste ich ein FHEM/lib/File Verzeichnis zum fhemupdate Prozess hinzufuegen, damit es verteilt wird, ich will aber eigentlich kein zweites CPAN aufbauen. Wie sollten wir solche Faelle loesen?

- ccurpcd.pl ist ein separat gestarteter Server, was einerseits mit der CCU per XML::RPC kommuniziert, andererseits mit FHEM via File::Queue (!). Problem Nummer eins ist, dass ich nicht weiss, wo ich solche Dateien einchecken soll, damit sie per update verteilt werden. Problem Nummer zwei ist, dass ich eigentlich gegen solchen Architektur-Wildwuchs (und das war noch milde formuliert  ) bin. Ich sehe aber auch die Interessen der Benutzer, die einfach an aktuelle Versionen kommen wollen.

Ich tendiere dazu, ccurpcd.pl nicht nach FHEM zu lassen, damit eruebrigt sich auch das RPCQueue Problem, und der Autor ist genoetigt, eine FHEM-konformere Architektur zu verwenden, was im Endeffekt dem Endnutzer zugute kommt.

Ich brauche noch weitere Meinungen, da ich nicht ganz entschlossen bin.

[Wuppi68]

meine Meinungum eine FHEM Kompatible nicht CPAN 2. Edition pflegen und aufbauen zu müssen:

wenn ein Modul Besonderheiten benötigt, dann kann wäre meine pragmatische Lösung:

FHEM/<Modulname>.pl  --> Modul selbst
FHEM/<Modulname>.d  --> Ökosystem für das Modul

[betateilchen]

• Ich glaube nicht, dass HMCCU ein Modul ist, das von so vielen Nutzern eingesetzt werden wird, dass ein solcher Aufwand im Abweichen des "fhem Standards" gerechtfertigt ist
• Anstatt darüber nachzudenken, wie man das handling von Modulen mit ihren Abhängigkeiten vereinheitlichen kann, machen wir immer mehr Dinge immer komplizierter
• Wenn zusätzliche Dienste/Server benötigt werden, sollten die nicht Bestandteil von fhem werden. Siehe auch hmland
• fhem sollte keine perl-Standardmodule in modifizierter Form ausliefern
• ...

[zap]

Da ich als Autor hier nicht neutral bin, hier nur kurz die Beweggründe für RPCQueue und ccurpcd.pl:

RPCQueue.pm: Das Originalmodul File::Queue hat einen Bug. In einer Schleife werden Hash-Elemente gelöscht und in der Schleifenbedingung "each %hash" verwendet. In älteren Perl-Versionen ging das, in neueren => Laufzeitfehler. Das Problem ist bei CPAN seit 1 Jahr gemeldet.
Workaround: Ich baue die paar Zeilen Code aus RPCQueue direkt in 88_HMCCU und ccurpcd ein. Könnte ich mit leben, auch wenn es meinem (Software-)Architekturverständnis widerspricht

ccurpcd.pl: Der RPC-Server kann theoretisch über den FHEM Webserver laufen. In der Praxis führt das aber dazu, dass FHEM nicht mehr bedienbar ist. Daher der Ansatz, das über einen separaten Prozess zu lösen.
Workaround: Ich mache das so wie z.B. 00_SONOS.pm. Da steckt der externe Prozess im Modul selbst.  D.h. 00_SONOS.pm wird von FHEM geladen. Gleichzeitig forked sich das Modul aber als Child selbst. Über den daraus entstehenden Code kann man zwar geteilter Meinung sein, aber wenn es läuft ...

Ich verstehe natürlich, wenn ihr nicht wg. jedem Modul die Architektur ändern wollt. Wenn es halt gar nicht geht, dann eben Github.

UPDATE: Last mal. Je mehr ich über das oben geschriebene nachdenke, desto attraktiver erscheint mir die Lösung, alles in HMCCU zu packen und RPCQueue und ccurpcd zu entsorgen. Mal sehen ...

[rudolfkoenig]

@Wuppi68: in der ersten Zeile sprichst du dich gegen CPAN Replizierung aus, in der letzten dafuer. Das ist verwirrend.

Je mehr ich über das oben geschriebene nachdenke, desto attraktiver erscheint mir die Lösung, alles in HMCCU zu packen und RPCQueue und ccurpcd zu entsorgen.

Ich glaube so eine Loesung wuerde auch das Leben der Benutzer vereinfachen.

Soweit ich XML::RPC verstanden habe, ist eine vollstaendige Integration in die FHEM select-Schleife moeglich, allerdings erfordert es Zeit, und Erfahrung mit Netzwerkprogrammierung. Alternativ verwendet man BlockingCall, dann kann man XML::RPC::Server->server_loop weiter verwenden. In diesem Fall kommuniziert man mit BlockingInformParent mit FHEM und auf File::Queue kann man verzichten.

[Wuppi68]

@Wuppi68: in der ersten Zeile sprichst du dich gegen CPAN Replizierung aus, in der letzten dafuer. Das ist verwirrend.

ich würde sagen Ergebniss offen

der Trick an dem Ökosystem ist, dass es bei dem Modulverantwortlichen bleibt und nicht an eine zentrale Library delegiert werden muss

[rudolfkoenig]

Mag sein, aber im schlimmsten Fall verteilen wir damit das komplette CPAN X-mal, jeweils einmal fuer jedes FHEM-Modul.
Das passt mir gar nicht.

[zap]

Ok, schaue mir BlockingCall mal genauer an und entscheide dann, ob ich das nutze oder die Variante "SONOS". Ziel ist auf jeden Fall, ohne CPAN Kopie und ccurpcd auszukommen. Melde mich dann nochmal wg. Checkin in FHEM, sobald es nur noch die 88_HMCCU* Files gibt.

Gibt es irgendwo eine Beschreibung wie BlockingCall funktioniert? Die Module, die ich gefunden habe, nutzen das, um einen asynchronen Request auszuführen, der irgendwann ein Ergebnis zurückliefert. Aber was passiert, wenn ich damit eine Endlos-Schleife starte (z.B. einen RPC-Server)?

[Markus Bloch]

Ist im Wiki dokumentiert

[zap]

ok, danke! Sehr gute Beschreibung. 2 Fragen habe ich jetzt noch:

1) Wenn ich den Timeout in BlockingCall weglasse, wird die Funktion endlos ausgeführt? Oder gibt es einen Default Timeout?

2) Wie verhält sich BlockingInformParent bzw. FHEM, wenn sehr viele Infos an den Parent Prozess zurück geschickt werden? Ich bekomme im RPC-Server für meine 400 Homematic-Kanäle in der Spitze 300 Events / Sekunde. Mit der File-Queue in einer RAM-Disk läuft das gut (ist eben eine Queue). Bei BlockingInformParent würde das aber sofort in FHEM aufschlagen und nicht häppchenweise.

[rudolfkoenig]

Es gibt kein default timeout.
BlockingInformParent uebertraegt die Daten via TCP/IP an das Basis-FHEM Prozess, und ruft da die spezifizierte Funktion auf. Duerfte effizienter sein als ein File-Queue, aber der Empfaenger kann nicht (ohne weitere Mechanismen) sagen, ich verarbeite nur ein Event, und den Rest mache ich spaeter.

[Dr. Boris Neubert]

Hallo,

ccurpcd.pl: Der RPC-Server kann theoretisch über den FHEM Webserver laufen. In der Praxis führt das aber dazu, dass FHEM nicht mehr bedienbar ist. Daher der Ansatz, das über einen separaten Prozess zu lösen.

schau Dir bitte mal FHEM/subprocess.pm an. Im contrib gibt es ein Beispielmodul für Ausbildungs- und Dokumentationszwecke.

Viele Grüße
Boris

[zap]

Hallo,

schau Dir bitte mal FHEM/subprocess.pm an. Im contrib gibt es ein Beispielmodul für Ausbildungs- und Dokumentationszwecke.

Viele Grüße
Boris

Hallo Boris,

was es nicht alles gibt ... man muss nur wissen, wo es steht

Das sieht sehr viel versprechend aus. Die Kommunikation Child - Parent dürfte sehr schnell sein. Das werde ich noch vor Blocking.pm mal testen.
Danke!

Viele Grüße
Dirk