Binaerdateien per update verteilen

[betateilchen]

sollte der Sourceforge mit ins SVN

du meinst wohl Sourcecode...

[michael.winkler]

So, jetzt bin ich am PC und kann etwas ausführlicher schreiben.

Grundsätzlich ist es ja so dass FHEM nur dann mit einem Endgerät kommunizieren kann wenn irgendeine Möglichkeit besteht dies über Netzwerk oder Ähnliche zu erreichen. In der Regel sind diese Schnittstellen von Haus aus schon am Endgerät oder über ein Gateway erreichbar.

Im Fall von dem 70_WINCONNECT.pm Modul ist es letztendlich genauso. Nur muss der Anwender zusätzlich auf seinem PC ein Stück Software installieren. Für mich als Entwickler des Modules und der Anwendung wäre es natürlich Wünschenswert wenn beides immer auf demselben Stand wäre.

Aus diesem Grund habe ich bei Rudi gefragt ob es möglich sein meine Anwendung für genau diesen Update Prozess hier ,,opt/fhem/www/winconnect" abzulegen.

Sollte das wirklich nur mit offenlegen meines Sourcecodes geht, werde ich diesen Schritt wahrscheinlich nicht gehen. Gerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden. Wer kann später schon wirklich unterscheiden ob die Anwendung von mir kommt oder von jemanden anderes.

Sollte mein Anfrage wirklich abgelehnt werden, muss ich mir halt andere Wege überlegen wie ich dem Anwender, so angenehm wie möglich, diesen Updateprozess gestalten kann.
Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.

Ich bin keinem Böse wenn Ihr meinen Antrag/Anfrage ablehnt.

Gruß
Michael

[dev0]

Aus meiner Sicht spricht nichts gegen die Veröffentlichung von Binaries im svn, wenn der aktuelle Sourcecode dazu im gleichen Repository veröffentlicht wird. Bei den Microcontroller Binaries störte es mich auch schon, dass ich erst auf die Suche gehen mußte und wahrscheinlich nur ähnlichen Code gefunden habe. Die Binaries selbst finde ich für Anfänger hilfreich.
Wenn der Source nicht verfügbar gemacht wird, dann haben Binaries mMn im FHEM Repository nichts zu suchen, es ist ein Open Source Projekt.

Ist halt fraglich ob es dem Anwender hilft wenn er den Sourcecode hat.

Dem reinen Anwender sicherlich nicht, aber es gibt zB. auch Entwickler, die FHEM nutzen, weil sie nicht die Katze im kaufen wollen.

Gerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden.

Diese Gefahr besteht bei Binaries immer. Auch Dir kann man nur vor den Kopf gucken und nicht hinein. Das ist jetzt nicht persönlich gemeint und ich möchte Dir auch nichts unterstellen.

EDIT: Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte. Bei diesem Gedanken ist mir schon klar, dass wir mit FHEM viele Geräte steuern, dessen Sourcecode wir nicht kennen. Wenn es aber die Möglichkeit gibt, dann sollten wir nicht darauf verzichten, zumindendest nicht weil einige/viele Anwender damit nichts anfangen können oder jemand alternative Binaries veröffentlichen kann.

[Dr. Boris Neubert]

Hallo,

bei FHEM geht es um Open Source. Das ist auch der Vereinszweck des FHEM e.V. als Betreiber der Infrastruktur. Eine weitere Befassung mit der Frage, ob ein Binary über das Update verteilt wird, ergibt nur Sinn, wenn vorab geklärt ist, dass der Quellkode verfügbar gemacht wird.

Viele Grüße
Boris

[Thorsten Pferdekaemper]

Hi,

Sollte das wirklich nur mit offenlegen meines Sourcecodes geht, werde ich diesen Schritt wahrscheinlich nicht gehen. Gerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden. Wer kann später schon wirklich unterscheiden ob die Anwendung von mir kommt oder von jemanden anderes.

Das ist meiner Meinung nach ein etwas seltsames Argument. Damit könnte man jegliche Open-Source-Entwicklung "erschlagen". Normalerweise wird es anders herum gesehen: Open Source macht die Software sicherer, weil man sich zumindest theoretisch davon überzeugen kann, dass da nichts "gefährliches" schlummert.

Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.

Das kann schon sein, aber...

• Das wurde soweit ich weiß auch schon kritisiert.
• Ich glaube, da geht es tatsächlich um Lizenzprobleme.
• Es ist im contrib-Ordner
• Nur weil es anderswo falsch läuft, kann man es bei sich trotzdem "richtig" machen.

Hmmm... Das klingt jetzt alles so, als ob ich absolut dagegen wäre, es an dieser Stelle dem Benutzer einfacher zu machen. Das wollte ich damit nicht sagen. Ich finde es aber inakzeptabel, etwas mit FHEM zu verteilen, zu dem man keinen Quellcode hat, insbesondere wenn das in Frage stehende Stück Software für FHEM entwickelt wurde, der Quellcode zur Verfügung steht und es keine rechtlichen Probleme gibt.

Gruß,
   Thorsten

[Dr. Boris Neubert]

Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.

Ich bin der Ansicht, dass wir diese Datei aus dem Repo entfernen sollten.

[CoolTux]

Ich bin der Ansicht, dass wir diese Datei aus dem Repo entfernen sollten.

Da bin ich der erste der dabei ist. Zumal das ganze seit Jahren mehr schlecht als Recht in Betrieb zu nehmen ist.


Zurück zum eigentlichen.
Unter ./www hat das ganze schon mal gar nichts zu suchen.
Ich bleibe bei meinem Vorschlag und möchte diesen gerne noch bestärken
Nur mit Sourcecode bekommt Micha einen eigenen Ordner unterhalb von Contrib. Dieser Ordner wird NICHT für Update bereit gestellt. Micha baut in seiner Commandref oder seinem Modul ein Link ein unter dem man die Datei vom SVN runterladen kann.


Grüße

[betateilchen]

Zumal das ganze seit Jahren mehr schlecht als Recht in Betrieb zu nehmen ist.

@CoolTux: WebViewControl liegt sicher nicht ohne Grund in ./contrib 

(Wobei der Browser, der im gerade diskutierten zip enthalten ist, bei mir einen tollen Job in Kombination mit InfoPanel macht. Unabhängig davon, ob man das zu wvc gehörende perl Modul einsetzt oder nicht)

[krikan]

Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.

Der Sourcecode ist afaik hier öffentlich: https://github.com/kc-GitHub/WebViewControl

[michael.winkler]

Die ganze Diskussion führ doch jetzt an allem vorbei!

Hallo,

bei FHEM geht es um Open Source. Das ist auch der Vereinszweck des FHEM e.V. als Betreiber der Infrastruktur. Eine weitere Befassung mit der Frage, ob ein Binary über das Update verteilt wird, ergibt nur Sinn, wenn vorab geklärt ist, dass der Quellkode verfügbar gemacht wird.

Viele Grüße
Boris

Diese Aussage trifft es doch. Über genau diese Punkt sollte diskutiert werden. Legt doch einfach die Rahmenbedingen für eine Binaerdatei fest und gut ist. Dann könnt ihr bei der nächsten anfrage ganz klar auf diese verweisen, und alle wissen bescheid.

EDIT: Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte.

Wenn ich dann solche Aussagen lese kann man nur mit dem Kopf schütteln.

Hmmm... Das klingt jetzt alles so, als ob ich absolut dagegen wäre, es an dieser Stelle dem Benutzer einfacher zu machen. Das wollte ich damit nicht sagen. Ich finde es aber inakzeptabel, etwas mit FHEM zu verteilen, zu dem man keinen Quellcode hat, insbesondere wenn das in Frage stehende Stück Software für FHEM entwickelt wurde, der Quellcode zur Verfügung steht und es keine rechtlichen Probleme gibt.

Das kann ich so nicht ganz bestätigen. Grundsätzlich ist die Anwendung ein Abfallprodukt aus einer anderen Entwicklung. Dort gibt es die Anwendung als Windows-Dienst und wird über eine andere Plattform abgefragt. Da ich privat einen FHEM Server verwende, entwickle ich dementsprechend für beide Plattformen. 

Ich für mich habe aus Eurer Diskussion herausgehört dass der Großteil von Euch es nicht möchte und genau darauf stelle ich mich jetzt ein.

Gruß
Michael

[Dr. Boris Neubert]

Hallo,

wie Rudi bereits schrieb: eine Mehrheitsentscheidung wird es in dieser Sache nicht geben. Wir hören die unterschiedlichen Positionen an und entscheiden dann.

Viele Grüße
Boris

[Markus M.]

Wenn ich dann solche Aussagen lese kann man nur mit dem Kopf schütteln.

Warum? Würdest du das auch noch denken, wenn z.B. jemand ein Modul im SVN haben möchte, das nur mit seiner eigenen, kostenpflichtigen iOS/Android/Win App funktioniert?

Ich für mich habe aus Eurer Diskussion herausgehört dass der Großteil von Euch es nicht möchte und genau darauf stelle ich mich jetzt ein.

Ich habe herausgehört dass alles ok ist, solange der Quellcode zur Verfügung steht.
Und das gilt selbstverständlich auch nur für den FHEM-kompatiblen Teil.

Zurück zum Beispiel WebViewControl:
Hätte ich den Quellcode an dem Punkt gehabt an dem ich ihn gebraucht hätte weil es mit meinen Geräten inkompatibel war, würde ich es heute wahrscheinlich einsetzen und hätte die Entwicklung unterstützt. So ist es mehr oder weniger eingeschlafen.
Und das ist ein weiterer wichtiger Punkt: Zukunftssicherheit. Wenn du mal keine Lust mehr hast dich um das Modul zu kümmern, sollte es zumindest möglich sein dass jemand anders übernimmt.

[CoolTux]

Zurück zum Beispiel WebViewControl:
Hätte ich den Quellcode an dem Punkt gehabt an dem ich ihn gebraucht hätte weil es mit meinen Geräten inkompatibel war, würde ich es heute wahrscheinlich einsetzen und hätte die Entwicklung unterstützt. So ist es mehr oder weniger eingeschlafen.
Und das ist ein weiterer wichtiger Punkt: Zukunftssicherheit. Wenn du mal keine Lust mehr hast dich um das Modul zu kümmern, sollte es zumindest möglich sein dass jemand anders übernimmt.

Hihi, wenn ich da mal ein kleines Gegenargument bringen darf. Hätte dieses vermaledeite Webviewcontrol damals bei mir vernünftig funktioniert, gebe es heute AMAD nicht.
Also ich bin froh darüber das es heute AMAD gibt. 

[michael.winkler]

Warum? Würdest du das auch noch denken, wenn z.B. jemand ein Modul im SVN haben möchte, das nur mit seiner eigenen, kostenpflichtigen iOS/Android/Win App funktioniert?

Es gibt sehr wohl Module, welche auf kostenpflichtige Teile angewiesen sind. Selbst AMAD benötigt einen Softwareteil der Geld kostet. Und auch diese Software hat sicherlich seinen Sourcecode nicht veröffentlicht. Soll das Modul dann auch ausgeschlossen werden? Ich denke eher nicht, und genau aus diesem Grund kann ich über die Aussage "Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte" nur den Kopf schütteln.

Hihi, wenn ich da mal ein kleines Gegenargument bringen darf. Hätte dieses vermaledeite Webviewcontrol damals bei mir vernünftig funktioniert, gebe es heute AMAD nicht.
Also ich bin froh darüber das es heute AMAD gibt. 

Wenn morgen jemand ein besseres Modul schreibt und dadurch meines verdrängt wäre das für mich auch nicht schlimm. So etwas passiert immer wieder mal.

Um mal wieder zum wesentlichen zurückzukommen. Für WinnConnect macht es keinen Sinn die GUI an einen Ort zu legen wo ich sie im laufenden Betrieb nicht über einen HTTP://fehserver:port/.... abholen kann. Deswegen braucht wir auch darüber nicht zu diskutieren. Im aktuellen ./www Verzeichnis sind heute schon einige Skript / Code usw. drin, ob da jetzt noch eine EXE dazukommt wäre für mich nicht schlimm. Generell wäre diese Diskussion aber erst dann zu führen, wenn generell geklärt wäre ob auf dem FHEM SVN eine Anwendung liegt wo der Sourcecode nicht zur Verfügung steht. Aber aus Lizenzrechtlichen Gesichtspunkt nicht dagegen sprechen würde.

Ich persönlich kann es verstehen wenn die FHEM Entwickler diese nicht wollen, und bin hier auch keinem Böse. 

[CoolTux]

Um mal wieder zum wesentlichen zurückzukommen. Für WinnConnect macht es keinen Sinn die GUI an einen Ort zu legen wo ich sie im laufenden Betrieb nicht über einen HTTP://fehserver:port/.... abholen kann. Deswegen braucht wir auch darüber nicht zu diskutieren. Im aktuellen ./www Verzeichnis sind heute schon einige Skript / Code usw. drin, ob da jetzt noch eine EXE dazukommt wäre für mich nicht schlimm.

Die Datei muß nicht unter www liegen. Am Anfang konnte man die xml AMADautomagicFlowsets auch über die Detailseite seines definierten AMAD Devices runterladen. Dabei spielte es keine Rolle das das Flowset unter ./FHEM/lib/ lag.
Du musst nur eine entsprechende Funktion in Deinem Modul einbauen.


Grüße