Ich habe einen Wrapper für HttpUtils_NonblockingGet als FHEM Befehl "wget" umgesetzt, der auch die Möglichkeit bietet die Serverantwort in ein Reading zu schreiben. Es soll definitiv kein HTTPMOD Ersatz oder Ähnliches sein/werden, sondern Anfängern die Möglichkeit geben http(s) URLs nicht blockierend aufrufen zu können ohne auf die Perlebene wechseln zu müssen.
Die Syntax wäre: wget <url> [<device>:<reading>] [optionale parameter]
Beispiele:
wget www.example.com/control?cmd=A¶m=1
wget www.example.com/test123 [devA:reading1]
wget www.example.com [devA:reading1] --method=POST --data="test 123"
Alle (Non)blockingGet Parameter können via command line angegeben werden, sind aber optional, wie das Reading auch.
Spricht etwas dagegen den Befehl "wget" ins svn einzuchecken?
Zitat von: dev0 am 22 Juni 2017, 11:40:18
Spricht etwas dagegen den Befehl "wget" ins svn einzuchecken?
Für mich spricht die Tatsache dagegen, dass es sich bei dem Namen "wget" um ein klar definiertes Linux Shell Kommando handelt. Wenn es nun einen FHEM Befehl gleichen Namens gäbe, ist die Verwirrung bei den Anwendern, die das nicht auf den ersten Blick unterscheiden können, vorprogrammiert.
Ähnliche Probleme haben wir ja hier im Forum schon immer wieder mit "sleep".
Der Name ist mir egal. Vorschläge?
Nach etwas grübeln finde ich den den Namen wget oder curl gar nicht so schlecht, da eine Suche nach den (bekannten) Begriffen vielleicht zum Ziel führen könnte. Eine Verwechselung mit einem Shell Befehl, im Gegensatz zu Perlbefehlen, sehe ich eigentlich auch nicht, aber das ist nur meine Meinung.
Es gibt aber bestimmt noch mehr Meinungen von anderen Entwicklern dazu....
Zitat von: dev0 am 22 Juni 2017, 12:08:37
Der Name ist mir egal. Vorschläge?
"httpget" oder "geturl"
Habe aber auch mit wget der curl kein Problem.
Sobald ein solcher Befehl unter "wget" oder "curl" auf FHEM-Befehlsebene zur Verfügung steht, wird es nicht lange dauern, bis die ersten User Aufrufparameter des Linux-Befehls zu versuchen und sich wundern warum das nicht funktioniert.
Und dann dauert es nicht lange, bis es irgendwelche Video- oder Blog-HowTos gibt, die dem User das Verständnis vermitteln, es basiert auf den Linux-Befehl wget/cURL. Daher bin ich ebenfalls dafür den Befehl "getURL" oder "getHttpUrl" o.ä. zu nennen, aber keinesfalls wget/cURL weils es tatsächlich nichts mit den Befehlen aus der Linux-Welt zu tun hat und auch ganz anders funktioniert. Kleines Beispiel: wget/cURL nutzen per default HTTP Protokollversion 1.1 in vollem Umfang (Keep-Alive / Chunking / etc.) während HttpUtils HTTP 1.1 nur sehr rudimentär beherrscht.
Für versierte Nutzer steht wget/cURL für ein universelles Werkzeug für HTTP/FTP/WebDAV/SFTP-Operationen. HttpUtils kann mit so viel nicht aufwarten.
Gruß
Markus
Danke für Eure Antworten. Mit den Namen getURL bzw. getHttpUrl komme ich klar.
Wenn keine anderen Einwände mehr kommen, dann werde ich es noch etwas rund machen und die Doku schreiben.
Ansonsten könnte man um die Benennung auch an die Vorbilder aus der Linuxwelt anlehnen.
Bspw. fwget oder fcurl (f für das F von FHEM)
Bleibt aber trotzdem das angesprochene Problem von Markus mit den Begehrlichkeiten, was den Funktionsumfang betrifft.
Zitat von: Benni am 24 Juni 2017, 08:39:41
fwget oder fcurl
Auch hier würde ich die Verwechselungsgefahr noch sehen, wie Du auch schon schriebst. Selbst wenn man noch telnet und ssh implementieren würde (was ich mir vorstellen kann), dann würden immer noch die meisten, von wget/curl unterstützen, Protokolle fehlen und der entsprechende Funktionsumfang wäre auch wesentlich geringer.
Bleibt aus meiner Sicht noch die Frage offen, ob man versuchen sollte mehrere Protokolle in einem Befehl unterzubringen (getURL) oder ob es sinvoller ist, mehrere Protokolle in getrennten FHEM Befehlen zu handhaben: getHttpUrl, getTelnetUrl, getSshUrl, ...
Getrennte Befehle hätte den Vorteil, dass verschiendene Maintainer sich nicht in Quere kommen. Für den Anwender fände ich einen getURL Befehl sinnvoller, da die Chance auf eine einheitliche Syntax größer ist.