Danke für die prompte und erhellende Antwort (Ich habs mir doch gedacht..)
lochness wrote:die Fritzbox "wächst" ja auch immer weiter und kann ja auch USB-Geräte betreiben. Man könnte sich also eine Lösung vorstellen, die dort ansetzt und Pakete auf USB Medien installiert und von dort aus startet.
Es gibt bereits eine Lösung:
[Zitat aus dem
freetz Wiki] Mit "External" kann dem Platzproblem im Flash der Fritzboxen entgegengewirkt werden, man kann also ein größeres Image als das Flash zulassen würde installieren. Hierzu werden Packages, Librarys als auch benutzerdefinierte Dateien aus dem Image "externalisiert" oder ausgelagert.
Bloß ändert das nichts daran, dass eben "nur komplette Images" geflasht werden könnten. Das ist ein gravierender Unterschied zu den SBLANs (und verwandten Geräten). Wobei, so richtig will mir das nicht einleuchten. Ich denke, es ist eine Einschränkung der Original-firmware, mit der die freetz-Entwickler umgehen müssen (wenn sie nicht alles komplett neu entwickeln wollen).
Aber das sind alles fremde Themem. Hier in diesem Forum geht es ja vorrangig um die Amseln und verwandte Vögel (auch wenn zuweilen ein Blick über den Zaun nicht schaden kann).
lochness wrote:Unser Paketkonzept ist zwar simpel aber nicht besonders gut (weil ich gern die einfache Installation für jedermann über Web-If drin haben wollte und das ist einfach nur ein "tar") und wenn ich das für eine andere Basis portieren müsste wo es noch nichts gibt, würde ich dann so was wie ikpg nehmen.
Heißt das, es gibt in der Original-fw ein vorgegebenes Paketkonzept? (Sonst hätte sich ja in der Tat ipkg angeboten). Übrigens, ich finds gut genug.
Was Lua angeht:
lochness wrote:Lua kenne ich nicht, gibt es da viele Programme?
Wohl eher nicht. Eine Referenz wäre das WebIF von
OpenWRT basierend auf
LuCI (für Lua Configuration Interface). Aufgrund des geringen Ressourcenbedarfs sei es gut geeignet für Geräte mit Kleinst-CPUs mit wenigen MB RAM. Zudem biete es "higher performance, smaller installation size, faster runtimes" als die übliche Kombination aus cgi und "heavy use of the Shell-scripting" (so wie bei der SBLAN).
Wenn auch der Schwerpunkt nach wie vor auf web user interface liegt, sind die
module eine Fundgrube für Entwickler. So bietet etwa die Klasse luci.i18n Sprachunterstützung an oder mit luci.http und luci.model.ipkg Schnittstellen zu http und ipkg.
Aber die SBLAN bringt ein recht brauchbares WebIF mit. Daher muss man das Rad nicht neu erfinden und dank üppiger 64MB RAM (im Vergleich zu 4-16MB eines routers oder 32MB einer Fritzfon) auch nicht mit Speicher knausern. LuCI wäre allenfalls eine Basis für eine Alternative zu NEXT_webadmin.
Daher gefällt mir eure bisherige pragmatische und minimalinvasive Vorgehensweise.
Apropos, gibt es eine brauchbare Doku zur API der Original-fw?