Binaerdateien per update verteilen

[herrmannj]

@Rudi: ich glaube, man will uns nicht verstehen.

Na, oder da gibts halt wenig zu verstehen Wenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht. Komisch ist schon

[betateilchen]

Wenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht

Aber genau darum geht es schon längst gar nicht mehr.

[rudolfkoenig]

Wenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht. Komisch ist schon

Gar nicht. Fuer contrib sind die Regeln laxer, fuer FHEM (und damit update) strenger. Ich will dem Entwickler Anreize geben, um unliebsame Aufgaben wie Doku und Support zu erledigen. Und fuer die Anwendern ist das ein Qualitaetsmerkmal.

Fuer Binaerdateien gilt diese Unterscheidung natuerlich nicht, aber ich will nicht grosse Dateien (wie Binaries haeufig sind), die man nicht braucht, ueberall verteilen. Die Grenze was gross ist und was man braucht ist nicht fuer alle gerecht zu ziehen, und ich habe sie als update-Maintainer etwas willkuerlich hier gezogen.

[michael.winkler]

Ist natürlich schwer zu beurteilen was grosse Dateien sind und was kleine, ich denke da hat jeder ein eigenes Gefühl dafür. Die WinConnect mit ca. 700kb gehört da sicherlich zu den etwas grösseren.

Ich verstehe auch die ganzen Argumente warum etwas ins contrib soll.

Mein anliegen war es einfach schon vorhandene Funktionen zu nutzen und nicht etwas anderes wieder zu erfinden. Aus diesem Grund habe ich überhaupt die anfrage bei Rudi gestellt. Vielleicht war diese Einstellung von mir zu naiv.

Wenn dann als Ergebnis raus kommt dass ich die Datei in ein Verzeichnis legen soll aus welchem ich sie dann später über einen HTTP(s) Aufruf erst wieder runterladen muss ist das etwas suboptimal. Für mich und den Anwender wäre es angenehmer gewesen schon integrierte FHEM Funktionen hierfür zu nutzen.

Dann wäre aus Anwendersicht eines ganz klar gewesen: Wenn er eine FHEM update macht ist alles was er nutzt auf dem aktuellsten Stand, und er weiß auch warum.

An manchen Aussagen und Argumenten ist halt doch immer wieder zu lesen

Das ist nicht unbedingt was fuer Anfaenger, aber FHEM war urpsruenglich auch nicht fuer Anfaenger gedacht

[Sidey]

Mal unabhängig von dieser Diskussion habe ich mir auch schon vor einiger Zeit überlegt, dass ich im Modul Daten wie Firmware oder Definitionen nachladen möchte. Das hat den Vorteil, dass ich Moduländerungen und Firmware oder Konfiguration unabhängig voneinander aktualisieren kann.

Auf jeden Fall etwas was aus meiner Sicht lohnenswert ist.

Bislang habe ich das nur aus einem Grund nicht umgesetzt: Komplexität.

Damit meine ich jetzt nicht, einfach einen HTTP Aufruf abzusetzen, das kriege ich schon noch hin, nein vielmehr ist es ja so, dass man den Update Mechanismus zum einen nonBlocking implementieren sollte und zum anderen den Anwender auch geeignet abholen muss. Sonst macht der ja nur das altbekannte Update und gut ist.

Das ganze kann jetzt jeder ganz individuell für sich erledigen. Mir würde ja gefallen, dass wir hier etwas einheitliches finden. Der Anwender wird es uns danken, wenn Dinge durchgehend gleich implementiert sind.



Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[CoolTux]

Ist natürlich schwer zu beurteilen was grosse Dateien sind und was kleine, ich denke da hat jeder ein eigenes Gefühl dafür. Die WinConnect mit ca. 700kb gehört da sicherlich zu den etwas grösseren.

Ich verstehe auch die ganzen Argumente warum etwas ins contrib soll.

Mein anliegen war es einfach schon vorhandene Funktionen zu nutzen und nicht etwas anderes wieder zu erfinden. Aus diesem Grund habe ich überhaupt die anfrage bei Rudi gestellt. Vielleicht war diese Einstellung von mir zu naiv.

Wenn dann als Ergebnis raus kommt dass ich die Datei in ein Verzeichnis legen soll aus welchem ich sie dann später über einen HTTP(s) Aufruf erst wieder runterladen muss ist das etwas suboptimal. Für mich und den Anwender wäre es angenehmer gewesen schon integrierte FHEM Funktionen hierfür zu nutzen.

Dann wäre aus Anwendersicht eines ganz klar gewesen: Wenn er eine FHEM update macht ist alles was er nutzt auf dem aktuellsten Stand, und er weiß auch warum.

An manchen Aussagen und Argumenten ist halt doch immer wieder zu lesen

Irgendwie drehen wir uns hier im Kreis.
Was nutzt es einem Anwender wenn Deine exe Datei im FHEM auf nem Raspi oder einer Fritzbox liegt? Gar nichts.
Also ist es doch angenehm wenn der Anwender auf seinem Windows PC FHEM im Browser aufruft, in die Detailansicht eines Devices von deinem Modul geht und dort auf Download WinConnect.exe drückt. Wobei sie auch gleich noch zur Installation angeboten wird. Der Download Link führt zum FHEM Contrib SVN wo Du immer die aktuellste Version ablegen kannst.
Ich begreife diese ganze Diskussion nicht mehr.

[michael.winkler]

Damit meine ich jetzt nicht, einfach einen HTTP Aufruf abzusetzen, das kriege ich schon noch hin, nein vielmehr ist es ja so, dass man den Update Mechanismus zum einen nonBlocking implementieren sollte und zum anderen den Anwender auch geeignet abholen muss. Sonst macht der ja nur das altbekannte Update und gut ist.

Guck mal hier, das geht schon. https://forum.fhem.de/index.php/topic,39124.msg312783.html#msg312783

Aber wie schon gesagt, man muss halt das Rad noch mal erfinden. 

[michael.winkler]

Irgendwie drehen wir uns hier im Kreis.
Was nutzt es einem Anwender wenn Deine exe Datei im FHEM auf nem Raspi oder einer Fritzbox liegt? Gar nichts.
Also ist es doch angenehm wenn der Anwender auf seinem Windows PC FHEM im Browser aufruft, in die Detailansicht eines Devices von deinem Modul geht und dort auf Download WinConnect.exe drückt. Wobei sie auch gleich noch zur Installation angeboten wird. Der Download Link führt zum FHEM Contrib SVN wo Du immer die aktuellste Version ablegen kannst.
Ich begreife diese ganze Diskussion nicht mehr.

Es geht darum dass das ein Anwender der kaum Ahnung hat damit seine Schwierigkeiten hat. Ist nun mal so. Wir, die hier gerade diskutieren haben mit so etwas keine Probleme. Des weiteren haben die Anwendung sicherlich mehr als nur einen PC. Jetzt das ganze wieder auf manuell zurückdrehen macht auch keinen Sinn.

Die winconnect.exe kann von Haus aus schon ein automatisches Update durchführen, wenn auf dem FHEM Server die Datei in einem entsprechenden Verzeichnis liegt. Es war aus meiner Sicht also alles schon vorhanden. Fehlte nur noch der Schritt die EXE auf dem FHEM Server aktuell zu halten.


Gesendet von iPhone mit Tapatalk

[CoolTux]

Dann bleibt also nur weiter Diskutieren, die WinConnect exe für SVN Download anpassen oder eigene Wege gehen.
Sag Bescheid wenn Du Dich entschieden hast. Die FHEM Community hat Dir meiner Meinung nach eine akzeptable Möglichkeit geboten.

[michael.winkler]

Dann bleibt also nur weiter Diskutieren, die WinConnect exe für SVN Download anpassen oder eigene Wege gehen.
Sag Bescheid wenn Du Dich entschieden hast. Die FHEM Community hat Dir meiner Meinung nach eine akzeptable Möglichkeit geboten.

Meine Entscheidung ist schon lange gefallen! Trotzdem wollte ich meine Meinung dazu noch mal klar stellen.