Closed kaihenkel closed 3 years ago
Ich hab hierzu einen Fork erstellt und bei mir in einem feature-branch abgelegt.
Welchen Benefit soll das ganze bringen? Außer das es die Installation für einen Normaluser deutlich umständlicher macht und den Ressourcenhunger noch weiter in die Höhe treibt. IMHO ist es deutlich sinnvoller ein separates non-UI-tool zu entwickeln, welches nur für server use ausgerichtet ist. Weiterhin ist zu beachten dass der client sowohl auf macOS, linux und windows mit dieser codebase funktionieren muss. Und wir unterstützen auch noch 32 bit clients.
Von daher halte ich die Idee in der Form nicht wirklich für sinnvoll, lasse mich aber gerne eines besseren belehren falls Du ein lauffähiges POC hinbekommst. Ich bin gespannt ob Du eine saubere Trennung hinbekommst da die codebase in Teilen schon 10 Jahre+ alt ist.
Da es sich hier nicht um einen Fehler handelt schließe ich das issue vorerst.
Ich finde es schade dass das Ticket so voreilig geschlossen wurde, da so keine einfache Kommunikation möglich ist. Vorteile einer Umstrukturierung wären:
Die Installation wird nicht notwendigerweise schwieriger, im gegenteil einfacher - da nur das verwendung findet was benötigt wird. Dies kann durch einen installer auf windows, package-manager unter linux und mac passieren.
Dieser Vorschlag war auch nur dahingehend gemeint die code-basis dahingehend umzustrukturieren dass das betreiben einer client-server trennung möglich ist, nicht dass es mit dem normalen aufbau automatisch passiert.
Ich habe das Ticket auch nur deswegen aufgemacht da ich fragen wollte ob von euerer Seite Interesse daran besteht die code basis aufzuräumen - dies scheint nicht der Fall zu sein. Ein POC kann man das nicht nennen wenn das gesammte System umgebaut wird - vor allem weil es wie du schon geschrieben hast auf altem, gewachsenen code basiert.
da so keine einfache Kommunikation möglich ist
Waaas? Wie kommst du denn auf sowas? Man sieht doch wie 100% einwandfrei die Kommunikation zwischen euch geklappt hat :)
Ziel:
Aufspaltung von Mediathekview in einen Client (Aktuelle GUI) und einen Server, welcher der die gesammte nicht GUI Funktionalität übernimmt.
Im aktuellen Sourcecode sind die Reinen GUI Klassen, Betriebsysthem spezifische Klassen und reine Service spezifischen Klassen (aktuell nicht als diese erkennbar) gemischt abgelegt, welches das Starten im Headless modus unmöglich macht. Eine aufsplittung in mehrere Module, z.B. desktop, server, utilities und ggf. weitere würde die Entwickling weiterer Features, die mit dem Aktuellen design unmöglich sind ermöglichen. (z.B. das Betreiben eines download servers auf einem seperaten System oder als Windows Service)
Ich würde ein Schrittweises Refactoring vorschlagen:
Sobald das geschafft ist, wäre ein server-only modul denkbar, welches über sockets / websockets mit dem desktop kommuniziert und auch ohne GUI lauffähig ist.
Bitte lasst mich wissen was ihr von der Idee haltet.