Unterstützung Modul CheckIn SVN

[martins]

Hallo zusammen,

ich benötige Unterstützung beim erstmaligen CheckIn des Moduls 98_Verkehrsinfo in das SVN.
Hat jemand die Zeit, einmal über das Modul drüber zuschauen ob alle Voraussetzungen gegeben sind für den SVN CheckIn oder es noch irgendwelche groben Schnitzer gibt?
Offene Baustelle ist noch die Englische commandref.
Getestet wurde dies bereits ausgiebig https://forum.fhem.de/index.php/topic,55118.0.html

Danke
martins

[CoolTux]

Was genau bedeutet offene Baustelle? Gibt noch keine englische Commandref? Soweit mir bekannt wäre das eine Voraussetzung.


Grüße

[martins]

Richtig, gibt noch kein, ist aber in Erstellung.
Unabhängig davon kann man ja schon einmal drüber schauen.
Mir geht es hauptsächlich darum, das nicht irgendetwas im Modul ist, was komplett gegen Fhem quer schießt oder man so nicht machen sollte.

[Markus Bloch]

Es gibt Anforderungen, die ein Modul erfüllen muss, damit es eingecheckt werden kann. Diese sind detailliert im Wiki beschrieben: http://www.fhemwiki.de/wiki/SVN_Nutzungsregeln (Abschnitt: "Technische Regeln")

Gruß
Markus

[martins]

@Markus Bloch,  ja richtig, diese habe ich auch soweit schon durchgearbeitet.
Mir geht es hier eigentlich um Qualitätskontrolle / Vieraugenprinzip nach dem das mein erstes Modul ist welches ich beitragen möchte.

[Markus Bloch]

Von der programmiertechnischen Umsetzung kann ich keine groben Schnitzer erkennen. Sieht alles soweit gut aus. Ich würde dir nur empfehlen auf HTML::TreeBuilder::XPath zu verzichten und den Inhalt via Regex aus der HTML-Struktur zu extrahieren.

Desweiteren würde ich der Funktion hf_orderby() noch den Modulnamen als Präfix voranstellen.

Aktuell wird der HTTP Aufruf Blocking via Blocking.pm gemacht. Das könnte man noch umstellen auf HttpUtils_NonBlockingGet(): http://www.fhemwiki.de/wiki/HttpUtils#HttpUtils_NonblockingGet

Viele Grüße

Markus

[Markus Bloch]

Du solltest noch "use Blocking;" am Anfang einfügen.

[martins]

Danke,
use Blocking;& Präfik habe ich hinzugefügt.  Da hat es schon was gebracht.

Ich würde dir nur empfehlen auf HTML::TreeBuilder::XPath zu verzichten und den Inhalt via Regex aus der HTML-Struktur zu extrahieren.

Regex, weil man dann auf ein weiters Modul verzichten kann oder gibt es andere Hintergründe? Mir fällt nähmlich AdHoc keine Idee ein um dies so zu lößen, da die Seiten dynamsich zusammengebaut werden und ich keinen richtigen Identifyer habe den ich verwenden könnte.

Die Funktion HttpUtils_NonBlockingGet() hatte ich mir angeschaut, aber nach dem ich ja schon Blocking verwende und ich mich dann schon im Fork befinde und den Hauptprozess nicht mehr belaste, dachte ich das ist dann nicht mehr nötig, aber ja könnte ich noch umbauen.

Viele Grüße
Martin

[Markus Bloch]

Regex, weil man dann auf ein weiters Modul verzichten kann oder gibt es andere Hintergründe?

Genau darum geht es. Man verzichtet auf nicht umbedingt nötige Abhängigkeiten. Bspw. Nutzer die FHEM auf der FritzBox ausführen, können keine zusätzlichen Perl-Module aus CPAN usw. nachinstallieren. Dort sind nur Perl Core Module vorhanden. Es gab im Forum immer wieder User die ein FHEM-Modul nutzen wollten, was bspw SOAP::Lite verwendet. Diese Nutzer konnten dieses Modul nicht auf der FritzBox installieren da es aus C-Sourcen kompiliert werden muss speziell für die FritzBox-Umgebung.

Wenn es natürlich von der Webseite her extrem schwierig ist die Daten via Regexp zu extrahieren muss man natürlich schauen, wie hoch der Aufwand ist, dass mit Perl-Boardmitteln zu lösen.

Die Funktion HttpUtils_NonBlockingGet() hatte ich mir angeschaut, aber nach dem ich ja schon Blocking verwende und ich mich dann schon im Fork befinde und den Hauptprozess nicht mehr belaste, dachte ich das ist dann nicht mehr nötig, aber ja könnte ich noch umbauen.

Der Hintergrund sind hier Nutzer die FHEM auf einer kleinen, schwachbrüstigen Hardware ausführen (z.B. ältere Raspberry, Cubietruck, Beaglebone). Wenn man in einem Modul Blocking.pm verwendet und damit einen Task startet, dann wird der gesamte FHEM Prozess geforkt und damit ein Prozessabbild im Arbeitsspeicher kopiert. Jenachdem wie groß die eigene FHEM-Installation ist, kann dies solche kleine Hardware an Speichergrenzen bringen, womit ein solcher BlockingCall nicht durchgeführt werden kann, da kein Speicher mehr zur Verfügung steht. Momentan kann man die parallele Ausführung solcher BlockingCalls als User begrenzen um auf kleiner Hardware nicht in solche Speicherprobleme zu laufen.

Die Funktion HttpUtils_NonBlockingGet benötigt dagegen keinen Fork sondern nutzt die FHEM-internen Socket-Mechanismen aus um Non-Blocking auf die Serverantwort zu warten.

Gruß
Markus

[martins]

Danke für die Ausführliche Erläuterung.
Das Modul werde ich dahingehend noch einmal überarbeiten und auf HttpUtils_NonBlockingGet umbauen. Ob ich es mit RegEx gelößt bekomme. .. ich prüf es noch einmal.

Grüße
Martin

[martins]

Ich habe mir das jetzt noch einmal durch den Kopf gehen lassen.
Das heißt man sollte unter Berücksichtigung der Performance lieber auf HttpUtils_NonBlockingGet setzen und Blocking.pm vermeiden? Jedenfalls bei solchen Geschichten wo man Webseiten parst.
Gibt es die Möglichkeit ähnlich eines Blockingaufruf, aber ohne das ein kompletter Fork erstellt wird?

[CoolTux]

Ja gibt es, aber ob sich der Aufwand lohnt und das nicht bisschen Overkill ist ist die Frage.
Du kannst einen eigenen child Thread der nonBlocking läuft erstellen und lässt dann parent und child über TCP socket miteinander Daten austauschen.

[dev0]

Du kannst einen eigenen child Thread der nonBlocking läuft erstellen und lässt dann parent und child über TCP socket miteinander Daten austauschen

Ist das nicht genau das, was blocking.pm macht?

[CoolTux]

Nein. Blocking.pm macht einen fork von FHEM.
Was ich meine ist einen getrennt laufenden, ständig aktiven nonBlocking Thread worin dann die blockierenden Abrufe oder Abarbeitungen ablaufen.

[justme1968]

HttpUtils_BlockingGet sollte man vermeiden da es fhem blockiert. das ist die schlechteste variante.

HttpUtils_NonBlockingGet forkt nicht sondern ist in die event loop integriert und blockiert nicht. das ist die einfachste variante und sinnvoll wenn es nur um http abruf geht.

Blocking.pm forkt und der child prozess arbeitet asynchron und kann mit BlockingInformParent daten an den parent senden. normalerweise wird es genommen um nach dem forken einmalig etwas zurück zu geben und sich dann zu beenden. aber man kann auch mehrfach daten zurück geben. das ist geeignet wenn man nach dem start nicht mehr mit dem child prozess kommunizieren muss.

SubProcess.pm erlaubt einen child prozess zu starten und in beide richtungen zu kommunizieren. hier ist aber darauf zu achten das nicht die kommunikation selber wieder blockiert wenn der child hängt. hier hat man die meisten möglichkeiten, es ist aber am komplexesten.

gruss
  andre