Das ist wesentlich schneller als die AVM Variante, um genau zu sein
Was genau soll das heißen ... oder auch "was genau ist denn genau"? Inwiefern ist das "schneller" bzw. welche Zeit (bei "schneller" sollte es ja um eine Zeitdauer gehen) wird da von Dir gemessen?
Ich verstehe nicht so ganz, ob das jetzt die Verwendung der
alternativen Ausgabe im "gui_bootmanager" ist (also "get_values") oder ob Du das alles noch einmal komplett nachprogrammieren wolltest (über die unterstützten DualBoot-Modelle hinweg, denn das war ja ein Grund für die neue Implementierung, nachdem die erste eher auf VR9-Boxen beschränkt war).
Es geht mich zwar auch nichts an, was Du da wie machst ... aber daß ich im Rahmen von "modfs" diese Möglichkeit direkt in das AVM-Interface einbaue (und nur da), ist ja durchaus Absicht.
Erstens ist da i.d.R. gar kein Freetz-Interface vorhanden auf diesen Boxen und zweitens bedienen die meisten Benutzer ihre Boxen eben doch weiterhin über das AVM-GUI (denn da finden sie das, was sie täglich brauchen - z.B. die Anruflisten oder die Netzwerk-Übersicht - und nicht auf der Freetz-Oberfläche) und da stellt dann eher das Freetz-GUI den "Bruch" dar und die (inzwischen auch deutlich weniger gut dokumentierte) Schnittstelle für den etwas "spezielleren" Fall.
Genau dieses GUI war auch mal der Auslöser dafür, daß ich mich nach etwas anderem umgesehen habe ... zwar bestand der Bedarf, die Firmware zu modifizieren und ein paar zusätzliche Einstellmöglichkeiten bereitzustellen, aber dafür war das Freetz-GUI nun tatsächlich nicht geeignet (jedenfalls nicht "für Laien", das geht schon beim abweichenden Port los, auch wenn im AVM-GUI wohl immer noch ein Link auf das Freetz-GUI erzeugt wird) und es mußte etwas anderes her und damit auch die Möglichkeit, dieses "andere" irgendwie in die Box zu bringen.
Um den "Kern" dieser Behandlung - auch über die verschiedenen Modelle - einheitlich zu haben, habe ich ja die alternative Ausgabe der relevanten Daten vorgesehen und die Kenntnisse, wo in Freetz die passenden Datumsangaben zu finden sind, nachgerüstet.
Unterschiedlicher "Geschmack" war auch der Grund, warum ich das Sammeln der Daten noch einmal sehr deutlich (im Vergleich zur Version davor) von der Erzeugung der Ausgabe entkoppelt habe (auch wenn das - ebenfalls wieder absichtlich - nicht wirklich zwei getrennte Skript-Dateien geworden sind, von denen eine nur die Daten sammelt und die andere nur die Ausgabe erzeugt) ... ich fände es unnütz und Verschwendung von Ressourcen (aka Arbeitszeit), wenn man mehrere konkurrierende Implementierungen (im Kern, also beim Sammeln der Daten) hätte, die sich nur bei der Ausgabe der Daten am Ende unterscheiden.
Die mag durchaus Geschmackssache sein und da soll jeder machen, was er will (das AVM-GUI kennt der Benutzer eben immer auch noch parallel bzw. er muß/sollte es zumindest kennen) ... bisher wußte ich halt nichts von alternativen Ausgaben und das ist auch der Grund, warum bei "get_values" im Moment noch nichts gecacht wird:
https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1170.Ich überlege, ob man das nicht auf diesen Fall erweitern sollte ... wobei ich bisher eben die gesamte Ausgabe (inkl. generiertem HTML) zwischenspeichere und nicht die gesammelten Daten.
Wobei dieses fehlende Caching ja eher gegen Dein "schneller" oben sprechen würde, denn die Ausführung beim Sammeln der Daten braucht ihre Zeit, wenn man in die inaktiven Partitionen hineinschauen will ... ein weiterer Grund, warum ich das auf "einmalig" umgestellt habe und es (bei der Integration im Rahmen von "modfs") sogar schon beim Start ausführen lasse, wo es mit seinem Zeitbedarf nicht wirklich auffällt und normalerweise ändert sich das ja auch im Laufe eines Startzyklus nicht mehr bzw. in "modfs" ist dann auch wieder ein Refresh für die gecachten Daten eingebaut.
Wenn jemand (plausibel) weitere Daten braucht, würde ich das nachrüsten (sofern es nicht "zu speziell" ist - denn die CS-Nummer von Freetz bringt halt auch nur in Freetz etwas und ist da deutlich leichter zu finden, als im "gui_bootmanager" - um mal ein Beispiel zu nennen) und solange das Datensammeln vom "gui_bootmanager" erledigt wird, fühle ich mich auch für Probleme von Benutzern an dieser Stelle zuständig.
Daher meine "Neugierde" und so würde ich eben gerne wissen wollen, ob jemand die Daten "auf eigene Faust" sammelt, weil ich mich dann nicht "verantwortlich" fühlen müßte, sofern es dabei Probleme gibt.
Wobei es beim Zusammenspiel mit den neueren Inhouse-Versionen (hier habe ich die Unterschiede beim Speichern der Versionsangaben mal festgehalten:
https://www.ip-phone-forum.de/threa...r-firmware-intern.294029/page-81#post-2306405) ohnehin auch neue Probleme gibt, weil AVM dort einiges umgestellt hat ... nun kann man erst mal wieder raten, ob das auch Einzug in "offizielle Laborversionen" halten wird (und man es damit als Alternative bei der Suche nach den Versionsangaben implementieren sollte) oder nur ein "Versuchsballon" ist, der wieder verschwindet.
-------------------------------------------------------------------------------------------------
Es wäre aber auch - im Gegenteil zu "eher das Freetz-GUI nutzen" - in meinen Augen inzwischen sogar logischer, wenn man viel mehr vom Freetz-Interface auch in das AVM-Interface integrieren würde ... wobei das bei der Struktur (das ist ja ein CGI-Interface, vorwiegend mit Shell-Skripten) auch nicht ganz einfach ist (ein Delay im Shell-Code ist gleich auch ein "unresponsive interface").
Aber heutzutage würde wohl niemand mehr auf diese Weise ein GUI implementieren ... das ist weder dynamisch noch "responsive" (und auch wenn das deutlich überstrapaziert wird als Schlagwort, haben bestimmte Aspekte davon ja durchaus etwas für sich) und solange man da nicht ständige Refreshs (im Vordergrund, weil eben nicht nur die Inhalte, sondern die gesamte HTML-Struktur aktualisiert würde) macht, ist das immer eine ziemlich statische Angelegenheit und nur ein "Schnappschuß" eines Zustands zum Zeitpunkt, wo dieser erstellt wurde. Dabei wären ja auch ein paar Freetz-GUI-Seiten mit dynamischer Aktualisierung durchaus sinnvoll ... angefangen bei einer "Live-Ansicht" der verbundenen Clients für einen OpenVPN-Server bis hin zur LED-Anzeige für die Boxen, die sich hinter dem Schrank befinden.
Von der Möglichkeit, das auch mit anderen Geräten als einem PC und dem dort installierten Browser (mit entsprechender Auflösung) vernünftig zu bedienen, will ich gar nicht erst anfangen ... aber die Zeiten, wo man irgendetwas fix für "640x480 quer" implementiert hat (ja, ich weiß, daß einige Elemente im Freetz-GUI eine Breite von > 1000 px verwenden), sind lange vorbei und ich möchte mal sehen, wie man das Freetz-GUI auf dem 3,5"-Display eines RasPi bedienen will (das ist die Größe, die zur 3er-Platine paßt und wo das Display nicht die Größe des gesamten Gerätes bestimmt).
Das Freetz-Interface ist also einigermaßen "old style" (nicht nur vom Layout her) und bevor man dem neue Kunststückchen beibringt, sollte man es m.E. (mehr als meine persönliche Ansicht samt Begründung ist das aber auch nicht) erst einmal "modernisieren". Da das aber durchaus größere Anstrengungen erfordert und die heute wohl niemand mehr für Freetz leisten kann (und will), sollte man eher überlegen, ob man nicht für die wichtigsten Pakete ein anderes Interface dazupackt, was sich (meinetwegen nach Wahl des Benutzers - wobei es auch kein "entweder oder" sein müßte) in das AVM-GUI integriert.
Das muß ja nicht gleich heißen, daß die sich dann (wie der "gui_bootmanager" mit seinem "html_display") in eine bereits bestehende AVM-Seite einpassen müssen (das bot sich hier nur an in meinen Augen) ... man kann durchaus auch einen eigenen Menüpunkt dafür erzeugen und darunter dann diese Einstellungen ablegen.
Das mache ich für ein paar Seiten unterhalb des AVM-Punktes "Diagnose" auch so, wo mir der Weg von AVM über "Inhalt" einfach zu beschwerlich ist und die Seiten, die zu den eigenen Erweiterungen gehören, haben dann eben ihren eigenen Menüpunkt (auch um die optisch von den AVM-Seiten etwas abzugrenzen, denn das im Anschluß fehlerhaft anzeigende GUI und die Frage, ob der "normale Kunde" das am Ende AVM anrechnen würde, war ja der einzige Punkt, in dem AVM im Cybits-Prozess einen Teilerfolg verbuchen konnte):
Da muss man ständig AVM hinterherprogrammieren
Das ist beim Boot-Manager bisher nicht ein einziges Mal der Fall gewesen, seitdem ich die erste Version (für das "responsive design", denn da wurde tatsächlich vieles umgestellt) erstellt habe - jedenfalls kann ich mich an keinen Fall erinnern. Insofern haben wir von "ständig" vielleicht auch unterschiedliche Vorstellungen.
Bei anderen Patches, die direkt in das AVM-GUI eingreifen, kommt das schon mal vor (z.B. bei der Anzeige der VPN-Verbindungen in der Übersicht) ... aber das kann man m.E. auch kaum vermeiden.
Da die AVM-Versionen am Ende auch alle nach demselben Schema organisiert sind, kann man das schon in den Labor-Versionen wieder sehen, wie es in der Zukunft wohl aussehen wird bei so ziemlich jedem Modell ... man hat also i.d.R. die notwendige Zeit, um sich da erneut anzupassen - und inzwischen macht die fortschreitende Modularisierung bei AVM im GUI das noch deutlich attraktiver, es für eigene Zwecke nachzunutzen, anstatt da etwas eigenes bereitzustellen ... bis hin zur Frage, daß man auch das Freetz-GUI natürlich auf der LAN-Seite besser mit TLS implementiert und nutzt, wenn man "mit gutem Beispiel vorangehen" will.
Auch die Frage der Benutzerverwaltung hat AVM inzwischen deutlich weiter vorangetrieben, als das bei Freetz der Fall ist ... oder gibt es dort inzwischen auch "read-only user", die sich nur mit Statusinfos aus dem Freetz-GUI versorgen können (z.B. wieder bei der Frage, welche OpenVPN-Verbindungen aktiv sind) und nicht gleich auch alle Einstell- (und "Verstell-") Möglichkeiten ebenfalls haben?
Mir fallen bestimmt noch ein paar weitere Argumente
für die Benutzung des AVM-GUI ein ... solange das Freetz-GUI (bis auf Schönheitskorrekturen mit irgendwelchen Skins) funktional auf dem derzeitigen Stand bleibt, wird der Abstand am Ende ja sogar immer größer.
-------------------------------------------------------------------------------------------------
Wo es aber wahrscheinlich tatsächlich problematisch wird, ist die Unterstützung von Freetz für Firmware-Versionen bis zurück zum Hrn. Zuse ... damit kann man sich nicht mehr nur auf die jeweils aktuelle Masche von AVM einstellen und muß wirklich viele ältere Sachen parallel noch vorhalten oder gar solche Patches pro Version verwalten.
Da wüßte ich auch keine andere Lösung, als einfach die alten Zöpfe abzuschneiden ... denn an die "Masse" an FRITZ!Box-Besitzern, die krampfhaft mit älterer (und fehlerbehafteter) Firmware arbeiten wollen, kann (und will) ich einfach nicht glauben. Meine eigenen Erfahrungen legen eigentlich nahe, daß die meisten Freetz-Benutzer immer zu den ersten gehören (oder das gerne würden), die auf eine neue Firmware-Version von AVM anspringen.
Unterschiede je Geräte machen
Ich bin etwas neugierig, wie man z.B. eine Puma-Box und eine 7490 hier "gleichbehandeln" sollte, wenn man anzeigen will, welches System jeweils installiert ist. Oder was meinst Du mit diesem "Unterschiede je Gerät machen" genau? Da, wo sich die Geräte vom Aufbau unterscheiden, muß man solche Unterschiede halt berücksichtigen.
Ich habe z.B. noch eine andere, bisher private Version (eine Mischung aus dem anderen Bootmanager und seiner Fähigkeit, Settings für jedes System getrennt zu verwalten und zu versionieren und dem aktuellen, garniert mit etwas TFFS-Verwaltung wie in "tbackup" - also alles nichts "Geheimes", sondern nur in einer etwas spezielleren Kombination, die zu erklären mir deutlich zu mühsam ist und die deshalb "unter Verschluß" bleibt) und bei der merke ich noch viel mehr, wie unterschiedlich schon die VR9-Boxen (konkret 7490 und 7412) bei der Behandlung von "/var/flash" vorgehen (mal liegt da die "config"-Partition und mal "nur" ein "tmpfs"). Wie sollte man da alle Geräte/Modelle über einen Kamm scheren können?
