Hmm, gute Riposte, das Sparring gefällt mir
Wo habe ich das denn vorgeschlagen?
Nirgends, war nur eine Schlussfolgerung, daraus, dass wenn das GUI den Index hält, jedes Programm, das diese Info braucht entweder selber sucht oder "den Teil des Systems abfragt, der davon weiss", ergo das GUI.
Nein. Die GUI soll ja eben nicht bei jedem Start die Disks durchsuchen.
Wenn sie selber einen persistenten Index hält, ok, wenn sie in nur volatil hält, müsste sie bei einem Neustart wieder nachschauen. Natürlich kann jedes GUI seinen Index/Cache führen, fänds nur platzsparender, wenn das zentral passieren würde und andere Programme darauf Zugriff hätten.
Abgesehen davon frage ich mich, wieso man überhaupt verschiedene GUIs einsetzen möchte? Wenn einem die Standard-GUI nicht gefällt, wird man die, so wie etwa beim GP2X auch, eventuell gegen eine andere GUI austauschen.
Logo, ist natürlich eine Randbedingung. Bestenfalls beim Evaluieren der GUIs würde man selten mal zwischen solchen Umschalten. Sollte mehr heissen "wenn der Index vom System angeboten werden würde, könnte jedes GUI(andere Apps) darauf zugreifen". Aber ja, der Use-case ist mehr übertriebene Erbsenzählerei.
Ich bezweifel, dass der ganze Suchvorgang überhaupt zu so einem großen Problem wird, wie hier behauptet. Ich denke, die meisten Benutzer werden nicht permanent neue Programme installieren. Hin und wieder sicherlich, aber das Installieren dürfte nicht der Haupteinsatzzweck der Pandora sein, sondern das Nutzen von Programmen und so lange sich nichts ändert muss auch gar nicht erneut nach Programmen gesucht werden.
Logo, der häufigste Fall ist natürlich das "Umstecken" von Karten. Und hier muss nur der (von wem auch immer produzierte) Index/Cache einer GUI/App mit der Kartennummer assoziiert werden (bzw. der Index wird auf die Karte direkt draufgeschrieben) und nicht gleich gedrobt werden, sobald mal eine andere Karte reinkommt. Wenn das funktioniert ist eine meiner Hauptsorgen für "potentiell nervendes Verhalten" schon weg. Aber meine andere Hauptsorge ist, dass man bei einem zentralen Index einfacher Apps erstellen kann, die "installierte" Apps referenzieren wollen und nicht jede App schreibt ihren Index/Cache auf jeder Karte, die sie findet. z.B. stecke ich meine Karte in eine Pandora beim Kollegen ein, der ein anderes GUI nutzt. Dieses erstellt daher einen eigenen Index/Cache und schreibt ihn auf meine Karte. Ich stecke diese wieder bei mir ein, mein GUI findet seinen Cache/Index wieder und macht nix, hab aber sinnloserweise die Cache/Index-Datei vom anderen GUI als Restmüll drauf.
...für die es sich deswegen erst recht nicht lohnt einen Dienst laufen zu lassen (egal wie groß oder klein) - jeder Start eines Dienstes verzögert schließlich den Bootvorgang. Die Bootdauer schätze ich als wesentlich kritischer ein, als den Vorgang des Suchens nach neuen Programmen.
Dies wurde schon früher oft diskutiert: Die Bootzeit spielt bei der Pandora keine Rolle, sie ist so konzipiert, dass sie sich immer wieder schlafenlegt und nicht runtergefahren werden muss. Das macht meine obige Aussage wegen GUI-Starts noch unbedeutender, da dieses dann auch fast nie neu startet.
Ich stelle mir das ganze mehr als Erweiterung im Betriebssystem-API, also evtl Teil des Kernels im User-Space vor (Da ich den Teil von Linux nicht so genau kenne, kann die Aussage auch etwas daneben liegen). Die Apps würden nur einen Systemaufruf machen falls nötig, anstatt, dass ein Demon dafür laufen müsste. Letzteres wäre für so eine kleine Aufgabe Overkill. Geschweige denn eine Deluxe Lösung, wo dieser auch noch INotify nutzen würde um auch jede Verschiebung/Löschvorgang einer PXML Datei mitzuverfolgen und real-time den Index upzudaten...
Was die anderen Verwendungsmöglichkeiten angeht, hast Du zwar einige Sachen aufgezählt, aber wirklich überzeugt, hat mich nichts davon.
Die PXML-Dateien sind in erster Linie dafür gedacht, dass eine GUI sich die "installierten" Programme zusammensuchen und sinnvoll in Kategorien einordnen kann. Man braucht aber, gerade weil man ja nicht wirklich installieren muss, kein System-Programm, dass einem die "installierten" Programme anzeigt - Programme, die man nicht mehr haben möchte, löscht man einfach von der SD-Karte. Fertig.
Zumindest die "Wecker-App", oder generischer "das Referenzieren/Aufrufen anderer Apps aus einer App heraus" sehe ich immer noch als wichtigen Use-case und dass eine App in Paketen "installiert" werden kann. Gut letzteres kann oft (aber nicht immer) auch mit der Bedingung "Die Pakete müssen im selber Folder liegen" abgehandelt werden. z.B. würde man für Doom weitere WADs im selben Verzeichnis wie das Programm selber entpacken.
... Programme, die man ohnehin nur von der Shell aus starten kann, gar nicht von PXML profitieren, weil eine Einordnung in Kategorien und Integration in die GUI sinnlos ist.
Mein Beispiel war missverständlich, die PXML Datei steht dabei nicht im Vordergrund, sie hat in dem Kontext nur den Sinn eines "Markers", der angibt wo überall Apps sind (aber auch das zugehörige executable angibt). Wirklich wichtig ist der zentrale Index. Das KommandozeilenStarterApp würde den Index nutzen um das zu startende App zu lokalisieren und das PXML auslesen um die Executable zu finden.
Wer tatsächlich seine installierten Spiele und Programme von der Shell aus starten möchte, wird sich vermutlich Symlinks ins bin-Verzeichnis packen können, um die Programme ausführen zu können, wobei selbst das ja relativ wenig Sinn macht.
... Solche Programme wird man ohnehin im Pfad haben.
Symlinks reicht nicht, die Apps werden ja jeweils mit dem "Installationsverzeichnis" als working directory gestartet. Und im Pfad sind sie schon gar nicht, denn wir reden ja gerade von den Apps, die nur per PXML "installiert" wurden. Und es geht nicht um einfache "Kommanzeilenwerkzeugen", die würde ich schon eher in ein Verzeichnis legen und dieses im PATH ergänzen. Mir gehts wirklich um die Gesamtheit aller dieser Apps, denn bei einer Auflösung von 800x480 werden die meisten von Ihnen sowieso im Fullscreen (per Framebuffer?) laufen und einige von Ihnen grad noch die GUI abschiessen. Wozu soll ich die dann noch starten?
Klar im Normalfall wird die GUI laufen, und ich kämpf nicht drum die Pandora auf der Kommandozeile zu bedienen (auch wenns mir nicht unsympathisch ist, denn ich möchte sie v.a. als Handheld für unterwegs nutzen und das Retro-Gamen ist ein fetter Pluspunkt). Sondern einfach nur um die Aussage: Wenn es einen zentralen vom System angebotenen Index hätte, könnte auch der Zugriff für alle anderen Apps viel einfacher ablaufen und (auch) sehr einfach per Kommandozeile. Ein AppLauncher wäre superschnell geschrieben und wenn ich mal schnell alle PXMLs auf der Disks nach etwas greppen möchte, kann ich das mit dem Index beschleunigen. Noch einfacher ausgedrückt: Systemeigener Index für alle --> Kein Nachteil für GUIs, aber einfachere Erstellung von Tools und Apps, die dies nutzen können.
Bei einem "normalen" Linuxsystem ist der Zugriff auf Informationen im installierten System einfacher, ich hab die Quellen für die Informationen immer irgendwo "gebündelt" (auf ein oder wenige Verzeichnisse). Während auf der Pandora die Infos über die installierte Software auf ein ganzes Medium verstreut ist. Jeder Zugriff erfordert zuerst ein "Zusammensuchen" der Infos. Ich kann auch kein Softwarepaket "referenzieren", weil der Pfad nicht stabil ist. Mit einer Referenzierung einer UUID ist das einfacher und jedes Programm, dass so eine Referenzierung auflösen muss ist froh um einen Index.
Ich behaupte auch weiter, dass eine Implementation möglich ist, bei der die GUIs dieselben Möglichkeiten haben (Zugriff schon während dem Scan) und das ganze als Betriebssystem-API Erweiterung sogar bessere Kontrollmöglichkeiten zum Verhalten hergibt (Veto, jede API, die Suchen möchte wird so aufgehalten). Und wenn du (und auch ED) argumentierst, dass sowieso selten gescannt wird und dies schnell gehen wird, wäre sogar (vorderhand für den ersten Release) eine Suche die erst am Schluss einen Zugriff auf die Ergebnisse ermöglicht ok, was die Implementation gar massiv vereinfacht (was ich natürlich nicht präferiere).