Ich vermute mal, es wurde keine zentrale Stelle für die XML-Dateien gewählt, damit Programm-Archive einfach irgendwo auf der Karte entpackt werden können. Damit soll dann das Programm "installiert" und sofort lauffähig sein. Ein Cache könnte bei Geschwindigkeitsproblemen echt eine ganz gute Lösung sein, jedenfalls dann, wenn der Cache automatisch von der GUI erstellt wird, so dass der Benutzer nichts davon merkt. Das wäre dann aber Sache der GUI.PandoraSuechtig said:Jedes GUI soll also die verdaechtigen Pfade nach PXML Dateien durchsuchen?
Als ich bei meinem P910i den Mediaplayer startete brauchte er immer eine Ewigkeit, bis er meinen 1GB Stick durchsucht hatte... Ich will nicht wissen wie so ein GUI auf der Pandora reagiert, wenn ich eine 64GB SD card einlege.
Zentralisiert die Geschichte, anstatt jedes GUI selber suchen zu lassen.
Ich empfehle eine "cache" (jeweils im root) Datei pro Medium (NAND, SD) die je nach Einstellung nur manuell oder bei jedem Medienwechsel automatisch den cache upgedatet wird.
Inhalt des Caches waere die Auflistung aller PXML Dateien auf diesem Medium, sodass all die GUIs sollten nur noch diesen Cache nutzen und die betreffenden Dateien direkt referenzieren.
Bestenfalls kann ich sogar beim Fuellen des Sticks auf meinem DesktopPC gleich noch den Cache erstellen lassen.
Wenn tatsächliche eine ID für jede Software vergeben werden soll, wäre wohl die einzige sinnvolle Variante UUIDs zu verwenden. So hat man für jede Software eine eindeutige ID, muss aber keine zentrale Verwaltungsstelle haben. Eine zentrale Verwaltung dürfte auf Dauer kaum praktikabel sein.PandoraSuechtig said:zu den IDs gibt es verschiedene Varianten:
- Bei jedem regenerieren des Caches erstellen, dabei sollten bestehende IDs wiederverwendet werdem um auf dem NAND gespeicherte Einstellungen zu Software auf der SD card nicht zu invalidieren.
- Jede Software wird bei pandora registriert und erhaelt eine eindeutige ID, die gleich in der PXML Datei genannt wird. Viel Arbeit fuer Pandora
- Jeder Entwickler/Studio erhaelt ein "Prefix" seine zu verwendenden IDs. z.B. "PND" und PND1212300. Immer noch aufwendig, aber machbar. Das ist ein aehnliches Konzept wie bei Java mit Packagenamen.
Wohl wahr. Autostart dürfte gerade Malware Tür und Tor öffnen, insbesondere, falls man auf der Pandora, wie beim GP2X, Programme immer als root ausführt.Im gleichen Atemzug:
Vermeidet jeglichen Autostart crap wie bei M$. Bringt nur Aerger, besser nur PXML Dateien und der Benutzer kann die Software manuell im GUI aufrufen. Den proprieaeteren Softwareentwicklern sollte ein Boot vom Medium ausreichen?
natürlich, wurde auch so in den anforderungen beschrieben. dem habe ich auch nirgends im beitrag wiedersprochenIch vermute mal, es wurde keine zentrale Stelle für die XML-Dateien gewählt, damit Programm-Archive einfach irgendwo auf der Karte entpackt werden können. Damit soll dann das Programm "installiert" und sofort lauffähig sein.
es geht nicht um geschwindigkeitsprobleme, das schafft die pandora im nebenbei (vermutlich auch mit zwei 64gb sd karten voll mit software in bruchteilen einer sekunde), sondern um effizienz und vermeidung von redundanzEin Cache könnte bei Geschwindigkeitsproblemen echt eine ganz gute Lösung sein,
du hast wirklich mühe damit beiträge ganz zu lesen :wink: ? genau darum geht es ja, trennung der kernfunktionalität (suche, cachen) von den guis (mehrere möglich!!). es soll gerade nicht von der gui erledigt werden. das ist ähnlich als würde man im fenstermanager die funktionalität eines x-servers einbauen.jedenfalls dann, wenn der Cache automatisch von der GUI erstellt wird, so dass der Benutzer nichts davon merkt. Das wäre dann aber Sache der GUI.
dies diskutiere ich im beitrag. denn UUIDs sind nur "sehr wahrscheinlich" unique. man kann die "uniqueness" etwas garantierter haben indem man z.b. jedem entwickler ein prefix zugesteht (mässiger aufwand). UUID bedeutet aber keinen verwaltungsaufwand für das pandorateam.Wenn tatsächliche eine ID für jede Software vergeben werden soll, wäre wohl die einzige sinnvolle Variante UUIDs zu verwenden. So hat man für jede Software eine eindeutige ID, muss aber keine zentrale Verwaltungsstelle haben. Eine zentrale Verwaltung dürfte auf Dauer kaum praktikabel sein.
dies ist ein diskussionsforum um die pandora zu optimieren, nicht um ein forum voller literarischer höhepunkte zu erschaffen.habe das Lesen nach dem ersten Punkt abgebrochen. ... aber richtige englische Sätze mit Punkt und Komma wären schon nicht schlecht gewesen.
hatte ihn gestern nacht um 1 geschrieben, da war ich nicht allzu erpicht alle typos zu entfernen und die grammatik ist über den ganzen text gesehen ziemlich ok.zumindest die Grammatik so grob stimmen würde, sonst ist das echt mühsam, das zu entziffern. Das sollte jetzt kein Angriff sein.
Was heisst das?? Sollen die Applikationsentwickler für die bestehenden GUIs erweiterte Infos einbetten/mitliefern können oder sollen die GUIs selber das PXML anpassen und ihre infos ablegen?? Letzteres würde mich erstaunen :wacko: :twisted:various informations
can be used to save configuration options from different GUIs (by adding their own config sections).
Dies stellt die userspezifischen settings pro GUI dar? Wenn man den Apps eine UUID verpasst, können die User/GUIs ihre Settings weniger verstreut halten und nur die UUIDs referenzieren.A second file (custconf.pxml) can reside in the same directory. It includes all users settings (i.e. Different categories)
and custom GUI configs. It overrides any settings that conflict with the default *.PXML, it always overrides the
complete categories section if it exists.
Natürlich geht es um den Inhalt und das hat niemand bestritten. Das heißt aber noch lange nicht, dass man nicht auf die Form achten sollte, denn die hat nicht etwa die Aufgabe, den Text schön aussehen zu lassen, sondern die Lesbarkeit zu erhöhen. Wenn Du dir nichtmal die Mühe machen möchtest, ein wenig auf die Form zu achten, kannst Du kaum erwarten, dass andere sich die Mühe machen, dein Geschreibsel zu entziffern. Sicher ist es oft irgendwie möglich, zu erahnen, was Du gemeint haben könntest, aber es ist in jedem Fall deutlich zeitaufwändiger. Da du ja offensichtlich anderen etwas mitteilen wolltest - sonst hättest Du den Beitrag ja gar nicht geschrieben - war ich davon ausgegangen, dass das eigentlich auch in Deinem Sinne sein sollte.PandoraSuechtig said:dies ist ein diskussionsforum um die pandora zu optimieren, nicht um ein forum voller literarischer höhepunkte zu erschaffen.habe das Lesen nach dem ersten Punkt abgebrochen. ... aber richtige englische Sätze mit Punkt und Komma wären schon nicht schlecht gewesen.
hier gehts um den inhalt, nicht um die form. drum geb ich mir nicht mal die mühe gross- kleinschreibung einzuhalten. übrigens hab ich schon einigen bücherschreibern als lektor gedient, da hat man nicht mehr lust die perfekte form auch in forentexten einzuhalten...
hatte ihn gestern nacht um 1 geschrieben, da war ich nicht allzu erpicht alle typos zu entfernen und die grammatik ist über den ganzen text gesehen ziemlich ok.zumindest die Grammatik so grob stimmen würde, sonst ist das echt mühsam, das zu entziffern. Das sollte jetzt kein Angriff sein.
Genau so hatte ich mir das auch gedacht!EvilDragon said:Ja, wie genau das mit dem Cache gehandhabt wird, wird GUI-Sache werden.
Ich erinnere mich an einen Mastersystem-Emulator (war es GP32 oder gp2x?), welcher innerhalb 2 Sekunden über 500 ROMs überprüft hat!
Da gings anhand der Checksumme.
Wenn eine GUI also eine kleine Routine hat, die kurz für eine Sekunde das Dateisystem nach neuen PXMLs durchforstet und diese dann parst, kann es sich das in einen Cache schreiben.
Das überprüfen könnte von der GUI tatsächlich kurz im Hintergrund stattfinden, sollte dann aber wirklich innerhalb kürzester Zeit abgeschlossen sein.
Und die GUI sollte natürlich auch einstellbar sein, dass sie nur auf Wunsch neu scannt
Du meintest XSD? DTD ist veraltet. Auch mit einem XSD kannst du nicht nachvollziehen was genau gemeint war, denn "Zuerst ein Description Element ohne lang Attribut" kannst du in einem XSD gar nicht ausdrücken. Dies spricht die exakte Darstellung an, im XSD definierst du aber den Inhalt. Soweit ich weiss war dies das erste XML Dokument von ED, daher wird er kaum ein XSD geschrieben haben.Wenn es eine DTD zu PXML gibt (existiert eine?), kann man dort ja genau nachvollziehen, wie es wirklich gemeint ist
Die Validierung ist auch von geringem Nutzen. Das Dokument ist sehr klein und ein Test auf der Pandora vor einem Release ist sowieso Pflicht. Nur wenn das Dokument noch stark anschwellen sollte, wäre eine Validierung beim Editieren mit einem XML-Editor nützlich.könnte damit natürlich auch überprüfen, ob eine Datei ein gültiges PXML-Dokument ist.
Warum? Begründe das. Vielleicht hast du ja mehr auf Linux entwickelt (ich nur wenig) und kannst das genauer erläutern, warum keine Hintergrundprozesse laufen sollten. Wegen solcher "automatischen Abläufe im Hintergrund" hatte ich früher die Option "nur manuelle Indexneuerstellung" genannt. Natürlich muss bei einem fehlenden Index sowieos zuerst mal einer erstellt werden.Caching sollte in jedem Fall (meine Meinung!) Sache der GUIs bleiben und eben nicht ausgelagert werden.
Auslagern würde nämlich bedeuten, dass im Hintergrund ein Indizierungsprozess laufen müsste,
oder ein solcher beim Starten und/oder Einlegen einer SD-Karte aufgerufen werden müsste.
Ein Indizierungsprozess im Hintergrund ist grundsätzlich eine sehr schlechte Idee, sollte also unbedingt vermieden werden.
Die Suche in die GUIs selber zu verlegen halte ich für den falschen Weg. Das führ ich jetz etwas aus:Beim Einlegen einer Karte ein Programm im Hintergrund zu starten (das für den Augenblick läuft und auch nur dann),
dass die Indizierung dann vornimmt, wäre zwar geringfügig besser, aber außer einer Liste der XML-Dateien könnte der
Prozess ja kaum sinnvoll weitere Informationen vorhalten (wie du ja auch schon geschrieben hast).
Dass eine GUI darauf ausgelegt sein sollte, möglichst angenehm bedienbar zu sein und zügig zu reagieren,
ist ja klar, aber wie sie das erreicht
(etwa durch interne Caching-Strategien oder parallele Ausführung von PXML-Dateiverarbeitung und Anzeige der GUI),
sollte Sache der GUI-Entwickler sein. Ich möchte jedenfalls nicht unnötige Hintergrundprozesse laufen haben.
Wenn es nur darum geht, nicht mehrmals das Rad neu zu erfinden, kann ja gerne jemand eine Bibliothek schreiben,
die diese Aufgaben erledigt (auch wenn das jetzt nicht wirklich komplex ist).
parallele Ausführung von PXML-Dateiverarbeitung und Anzeige der GUI
Dies ist eine andere Anforderung. Er prüfte den Inhalt "eines(?) Verzeichnisses" und berechnete die Checksumme von 500 ROMS. Ich denke, dass er dazu 500x ein paar Kilobyte gelesen hat (es reicht die Checksumme aus einigen kbytes der Dateien zu bilden), also 1 Verzeichnis lesen und aus ca. 2MB Checksummen erstellen.Ja, wie genau das mit dem Cache gehandhabt wird, wird GUI-Sache werden.
Ich erinnere mich an einen Mastersystem-Emulator (war es GP32 oder gp2x?), welcher innerhalb 2 Sekunden über 500 ROMs überprüft hat!
Da gings anhand der Checksumme.
Ich behaupte, dass dies beim Durchsuchen einiger Tausend Verzeichnisse auf einer 64gb SD nicht "innerhalb kürzester Zeit" geht. Ausser ihr definiert z.B. in was für einem Verzeichnis die Applikationen sein müssen, das schränkt schon mal die Suche ein und dürfte das Problem evtl. gänzlich entschärfen. Dann wird nicht der ganze Stick durchsucht wo ich z.B. in einem anderen Verzeichnis eine Sammlung von was auch immer mit vielen Unterverzeichnissen mit mir herumtrage.Wenn eine GUI also eine kleine Routine hat, die kurz für eine Sekunde das Dateisystem nach neuen PXMLs durchforstet und diese dann parst, kann es sich das in einen Cache schreiben.
Das überprüfen könnte von der GUI tatsächlich kurz im Hintergrund stattfinden, sollte dann aber wirklich innerhalb
kürzester Zeit abgeschlossen sein.
Das wär aber auch bitter nötig und bitte einzeln pro "disk" initierbar, nicht dass er bei einem "rescan" gleich alle drives disks durchwühlt.Und die GUI sollte natürlich auch einstellbar sein, dass sie nur auf Wunsch neu scannt
XSD ist ein Vorschlag des W3C, DTD ist Teil des XML-Standards. Spielt aber im Prinzip auch keine Rolle. In einer DTD kann man jedenfalls definieren, welche Attribute es gibt und welche davon optional sind und welche erforderlich. Das war doch genau das, worum es ging?!PandoraSuechtig said:Du meintest XSD? DTD ist veraltet.Wenn es eine DTD zu PXML gibt (existiert eine?), kann man dort ja genau nachvollziehen, wie es wirklich gemeint ist
Tatsächlich habe ich viel auf Linux-Systemen entwickelt, das ist aber nicht mal ein Linux-spezifisches Problem. Jeder Prozess verbraucht Ressourcen. Ein Hintergrundprozess tut dies immer. Das ist zum Einen ein bisschen Speicher (vielleicht mit 256 MB nicht mehr so gravierend, aber trotzdem kein Grund Speicher zu verschwenden), zum Anderen CPU-Zeit. Die CPU-Zeit steht anderen Programmen nicht zur Verfügung. Wenn man z.B. gerade ein Spiel laufen lässt und plötzlich meint der Hintergrundprozess, seinen Index zu aktualisieren wird sich das negativ auf die Performance auswirken. Wenn der Hintergrundprozess den Index automatisch aktualisiert, wenn ein Medium eingelegt wird, hat die GUI keinen Einfluss auf den Zeitpunkt. Wenn die GUI selbst dafür verantwortlich ist, kann ein günstiger Zeitpunkt gewählt werden, um den Einfluss auf die Bedienung gering zu halten.Warum? Begründe das. Vielleicht hast du ja mehr auf Linux entwickelt (ich nur wenig) und kannst das genauer erläutern, warum keine Hintergrundprozesse laufen sollten.Caching sollte in jedem Fall (meine Meinung!) Sache der GUIs bleiben und eben nicht ausgelagert werden.
Auslagern würde nämlich bedeuten, dass im Hintergrund ein Indizierungsprozess laufen müsste,
oder ein solcher beim Starten und/oder Einlegen einer SD-Karte aufgerufen werden müsste.
Ein Indizierungsprozess im Hintergrund ist grundsätzlich eine sehr schlechte Idee, sollte also unbedingt vermieden werden.
Aha, wieder was gelernt.XSD ist ein Vorschlag des W3C, DTD ist Teil des XML-Standards.
Achtung, jetzt wirds picky.... Eigentlich Ja, ich meinte aber dass es sich nicht ausdrücken lässt, dass das erste Element ohne Attribute ausgeschrieben sein muss. Man kann bestenfalls (zumindest in XSD) verlangen, dass das erste Element 'lang="en"' nutzt, was immer noch "<description>...</d..>" oder "<description lang=en>...</d..>"In einer DTD kann man jedenfalls definieren, welche Attribute es gibt und welche davon optional sind und welche erforderlich. Das war doch genau das, worum es ging?!
Ich würde mal vermuten, dass es nie so gedacht war, dass es erfoderlich ist, dass die Reihenfolge so sein muss, dass das Element für die Standardsprache als erstes kommt.
Englisch ist halt die Standardsprache und das Element dazu kann ja in jedem Fall sofort gefunden werden
Der Prozess würde aber immer auf Systemevents oder calls warten. Daher wäre er immer im Sleep und würde vom Scheduler nicht einen einzigen Takt abkriegen. Die Pandora könnte sich getrost schlafen legen. Das Argument greift daher nicht.Jeder Prozess verbraucht Ressourcen. ..., zum Anderen CPU-Zeit.
Wenn im Hintergrund das GUI noch laufen würde, würde es genauso auf das Einstecken einer SD reagieren. Man kann genauso gut im GUI wie auch im System für den Indexierungsservice einstellen "nur auf Wunsch". Da unterscheiden sich beide nicht. Argument greift auch nicht.Wenn man z.B. gerade ein Spiel laufen lässt und plötzlich meint der Hintergrundprozess, seinen Index zu aktualisieren wird sich das negativ auf die Performance auswirken.
Das GUI würde auch auf das Einlegen eines Mediums reagieren, aber den Scan verschieben. Genauso kann der Indexierer das Scannen aufschieben und auf einen Tritt vom GUI warten. Wenn ich hingegen mehrere Apps habe, die das neue Medium scannen wollen, habe ich konkurrierende Zugriffe, während der Indexierer es für alle genau ein mal erledigen würde. Dann wären sogar "Vetos" möglich, so dass wenn die eine App loslegen möchte mit Indexieren, kann die GUI das noch aufschieben. Während bei der "pro App" Lösung die GUI es sich zwar verkneifen kann, hintenrum aber die andere App schon mal ungehindert mit Suchen loslegt.Wenn der Hintergrundprozess den Index automatisch aktualisiert, wenn ein Medium eingelegt wird, hat die GUI keinen Einfluss auf den Zeitpunkt. Wenn die GUI selbst dafür verantwortlich ist, kann ein günstiger Zeitpunkt gewählt werden, um den Einfluss auf die Bedienung gering zu halten.
sleep state... siehe oben.Dazu kommt, dass der Prozess auch die Akkulaufzeit reduziert, wenn der permanent im Hintergrund läuft.
Kalt erwischt. Die Flash-Problematik hab ich glatt verpasst. Ich wüsste auch hier eine Lösung, aber das erfordert dann schon mehr Aufwand: z.B. Cachen im Memory, Interprozesskommunikation fürs Auslesen oder Unified FS mit einer Ramdisk, die das File erst am Ende auf die SD runterkopiert. Einfacher für die benutzende Soft und Indexfiles dürfen sowieso ruhig verloren gehen wenn zwischendurch das Medium entfernt wird.Der Vorschlag jeden Fund sofort in die Index-Datei zu schreiben, ist übrigens nicht gerade günstig für Flash-Speicher.
Insbesondere mit dem Ablegen von Lockfiles im NAND-Speicher sollte man aufpassen. Programme im NAND zu installieren ist eine Sache, regelmäßige Schreibzugriffe eine andere. Eine SD-Karte kann man ja immerhin austauschen.
Außerdem ist wenig gewonnen, wenn die GUI dann doch wieder auf den Prozess warten muss. Dann kann sie lieber selbst parallel neue Dateien suchen und dann anzeigen.
Ich glaube das Ganze ist halb so wild, weil ja eigentlich nichts dagegen sprechen dürfte, das Attribut einfach als optional zu kennzeichnen. Ich weiß, dass das laut dem PDF nicht unbedingt so interpretiert werden muss, aber vielleicht war es von ED ja sogar so gemeint und die Variante ohne lang wurde nur explizit erwähnt, weil das eben auch möglich sein soll.PandoraSuechtig said:Achtung, jetzt wirds picky.... Eigentlich Ja, ich meinte aber dass es sich nicht ausdrücken lässt, dass das erste Element ohne Attribute ausgeschrieben sein muss. Man kann bestenfalls (zumindest in XSD) verlangen, dass das erste Element 'lang="en"' nutzt, was immer noch "<description>...</d..>" oder "<description lang=en>...</d..>"
zulässt, da gleichwertig. Hey, ich hab dich gewarnt, dass es picky wird :lol:
Pollen sollte man natürlich wirklich nicht gerade, aber Speicher belegt der Prozess in jedem Fall und auch der Bootvorgang wird, wenn auch nur ein wenig, verlängert. Deswegen bin ich immer noch dafür so wenig Dienste wie möglich zu starten. Das Gerät ist schließlich kein PC und selbst da übertreiben es manche Linux-Distributionen (und auch Windows) ganz schön.Der Prozess würde aber immer auf Systemevents oder calls warten. Daher wäre er immer im Sleep und würde vom Scheduler nicht einen einzigen Takt abkriegen. Die Pandora könnte sich getrost schlafen legen. Das Argument greift daher nicht.Jeder Prozess verbraucht Ressourcen. ..., zum Anderen CPU-Zeit.
Selber schuld wer ihn als pollenden Prozess hackt...
Es ist ja so gedacht, dass die GUI eben nicht im Hintergrund läuft, sondern beim Start eines Programms komplett beendet werden kann, so wie es beim GP2X auch ist. In dem Fall wäre es auf jeden Fall ein Unterschied.Wenn im Hintergrund das GUI noch laufen würde, würde es genauso auf das Einstecken einer SD reagieren. Man kann genauso gut im GUI wie auch im System für den Indexierungsservice einstellen "nur auf Wunsch". Da unterscheiden sich beide nicht. Argument greift auch nicht.Wenn man z.B. gerade ein Spiel laufen lässt und plötzlich meint der Hintergrundprozess, seinen Index zu aktualisieren wird sich das negativ auf die Performance auswirken.
Ich würde eigentlich annehmen, dass in den aller meisten Fällen nur ein einziges Programm überhaupt auf den Index zugreift, nämlich die GUI. Selbst wenn man eine Auswahl an verschiedenen GUIs haben sollte, wird man ja nicht mehrere davon gleichzeitig laufen lassen.Mit einem Indexierungsservice meine ich nicht die banale ***** wie in Windows, sondern einen Eventgetriebenen Mechanismus, der problemlos abschaltbar ist. Wenn das Teil sich so stupid wie Windows oder der Office Autostart verhalten würde, wär ich auch voll dagegen. Aber genau wie beim Indexierungsservice kann es auch im GUI selber unzureichend implementiert werden. Dort aber muss die Logik in jedem GUI repliziert werden und es besteht kein ge"shart"er Index.
Das GUI würde auch auf das Einlegen eines Mediums reagieren, aber den Scan verschieben. Genauso kann der Indexierer das Scannen aufschieben und auf einen Tritt vom GUI warten. Wenn ich hingegen mehrere Apps habe, die das neue Medium scannen wollen, habe ich konkurrierende Zugriffe, während der Indexierer es für alle genau ein mal erledigen würde. Dann wären sogar "Vetos" möglich, so dass wenn die eine App loslegen möchte mit Indexieren, kann die GUI das noch aufschieben. Während bei der "pro App" Lösung die GUI es sich zwar verkneifen kann, hintenrum aber die andere App schon mal ungehindert mit Suchen loslegt.Wenn der Hintergrundprozess den Index automatisch aktualisiert, wenn ein Medium eingelegt wird, hat die GUI keinen Einfluss auf den Zeitpunkt. Wenn die GUI selbst dafür verantwortlich ist, kann ein günstiger Zeitpunkt gewählt werden, um den Einfluss auf die Bedienung gering zu halten.
Wenn der die ganze Zeit schläft, hast Du natürlich Recht, aber beim Einlegen einer Karte z.B. würde der Dienst ja aktiv werden - auch dann, wenn sich gar nichts verändert hat. Das ist ja ziemlich überflüssig.sleep state... siehe oben.Dazu kommt, dass der Prozess auch die Akkulaufzeit reduziert, wenn der permanent im Hintergrund läuft.
Es belegt weniger Speicher das ganze einmal ausprogrammiert zu haben als dies in mehreren Applikationen auszuprogrammieren. Sogar wenns nur das GUI benutzt ist der Speicherverbrauch identisch zur Lösung es als Service/Betriebsystembestandteil zu implementieren. Und wenns mehrere Programme nutzen, sparen wir sogar Speicher. Mir scheint du siehst dies als "fetten" Service, waehrend ich das als ziemlich klein einstufe oder es sogar als Erweiterung im Betriebssystem-API sehen würde. Spätestens hier wär der Unterschied an Performance/Speicherverbrauch gleich null (solange nur 1 App den Index nutzt). Ich vermute, dass du den Begriff "Service" (anhand des Vokabulars im Linuxbereich?) anders assoziierst, während ich ihn hier ziemlich abstrakt und weniger implementationsspezifisch benutze. Ich spreche mehr von der Architektur.Speicher belegt der Prozess in jedem Fall und auch der Bootvorgang wird, wenn auch nur ein wenig, verlängert. Deswegen bin ich immer noch dafür so wenig Dienste wie möglich zu starten. Das Gerät ist schließlich kein PC und selbst da übertreiben es manche Linux-Distributionen (und auch Windows) ganz schön.
Hatte ich schon im letzten Mail angesprochen: Vetos. Funktioniert sogar besser. Denn so wird jede Index-nutzende App "stillgelegt", während mit dem Abschiessen der GUI nur der Hamemr eingesetzt wird. Ich schreibe auch ausführlich von den Möglichkeiten, dass eine App/der Nutzer das Verhalten der Indexierung konfigurieren kann. Beides käme aufs gleich hinaus, kein Unterschied.Es ist ja so gedacht, dass die GUI eben nicht im Hintergrund läuft, sondern beim Start eines Programms komplett beendet werden kann, so wie es beim GP2X auch ist. In dem Fall wäre es auf jeden Fall ein Unterschied.
Exakt, genau hier liegt der Unterschied in unserer Argumentation. Denn meine letzten "offensiven" Fragen hast du mit diesem "Killerargument" es gäbe nur die GUI geplättet. Sobald aber auch nur eine andere App den Index nutzt, ist die Indexierung pro App ineffizienter, daIch würde eigentlich annehmen, dass in den aller meisten Fällen nur ein einziges Programm überhaupt auf den Index zugreift, nämlich die GUI. Selbst wenn man eine Auswahl an verschiedenen GUIs haben sollte, wird man ja nicht mehrere davon gleichzeitig laufen lassen.
Wenn jetzt tatsächlich viele Programme solche Suchen starten müssten, wäre ein Index vielleicht angebracht, aber ich hoffe doch mal stark, dass das nicht der Fall sein wird. Ich sehe auch nicht wirklich einen Grund dafür, wieso viele andere Programme ebenfalls die PXML-Dateien lesen sollten.
Siehe oben, Veto und Konfigurationsmöglichkeiten. Und nicht der Service, sondern das Betriebssystem wird auf den Event "Karte einlegen" reagieren und die Listener benachrichtigen. Das GUI wär abgeschossen, also ok, der Indexierungsservice kann sich genausogut von der Listenerliste abmelden, genauso effizient. Letzteres liesse sich auch bei einem zentralen Indexierungsservice konfigurieren. Während bei mehreren suchenden Apps zwar das GUI weg wäre, die anderen Apps aber frisch fromm fröhlich auf das Einlegen der Karte hin mit der Suche loslegen würden. Wenn das Suchen aber zentral implementiert ist, lässt es sich auch zentral abstellen.Wenn der die ganze Zeit schläft, hast Du natürlich Recht, aber beim Einlegen einer Karte z.B. würde der Dienst ja aktiv werden - auch dann, wenn sich gar nichts verändert hat. Das ist ja ziemlich überflüssig.
Wäre identisch wenn zentral implementiert, nur kann das GUI bequem den Service/API-call/... anstossen.Ich würde in der GUI eine Suchfunktion integrieren, die nach neuen Programmen scannen kann. Diese würde ich im Normalfall manuell aufrufen, weil der Benutzer ja eigentlich wissen sollte, ob er gerade ein Programm auf die Karte kopiert hat, oder nicht.
Wäre identisch wenn zentral implementiert, nur kann das GUI bequem den Service/API-call/... anstossen, der auch die Angabe eines Teilpfades oder eines Mediums erlaubt. Und diese Funktionalität wäre ALLEN APPLIKATIONEN zugänglich ohne es überall erneut zu implementieren und das eine GUI erlaubt nur eine Teilsuche, das andere kann alte Ergebnisse resynchronisieren, das dritte GUI verwirft die alten Ergebnisse und baut neu auf und das letzte GUI kann vieles besser aber wartet bis es seine Suche beendet hat...Zusätzlich könnte man es auch so machen, dass man der GUI sagt, in welchem Verzeichnis überhaupt nach Programmen gesucht werden soll, falls es nicht ohnehin eine Empfehlung für ein Programme-Verzeichnis gibt. Dann beschränkt sich die Suche auf dieses eine Verzeichnis (oder von mir aus auch einige wenige), womit die Dauer des Scanvorgangs, gegenüber einer ziemlich überflüssigen Komplettsuche, erheblich verkürzt werden dürfte.
Wäre identisch wenn zentral implementiert, nur kann das GUI bequem den Service/API-call/... anstossen. Hier wird einfach nur ausgeführt wie das GUI die Optionen des zentralen Indexierungs"services" dem Nutzer zum Anpassen zur Verfügung stellt. Das hat nix mit dem zu tun wo die Indexierung selber abläuft.Um das Ganze für den Benutzer möglichst komfortabel zu gestalten, könnte man beim ersten Einlegen einer SD-Karte automatisch nachfragen, ob und wenn ja wo nach Programmen gesucht werden soll und ob in Zukunft erneut gefragt werden soll, mit einem Hinweis darauf, wie man die Suche manuell anstoßen kann.
Hatte ich das nicht schon im zweiten Beitrag so geschrieben? Siehe (cache meint hier den Index):Den Index, den die GUI bei meinem Vorschlag erstellen würde, würde ich in dem Fall übrigens auf der SD-Karte, die gerade durchsucht werden soll, speichern. Dann stimmen die Pfade auch dann, wenn sich der Einhängepunkt ändern sollte, etwa, weil man die Karte mal in den anderen Slot gesteckt hat und der interne NAND würde auch nicht belastet.
Aha, meine Bemerkung ist missverständlich. Gemeint war mit "root" des jeweils gescannten Mediums. Darauf baute auch meine Anmerkung 3 Zeilen weiter auf (cache meint hier den Index):Ich empfehle eine "cache" (jeweils im root) Datei pro Medium (NAND, SD) die je nach Einstellung nur manuell oder bei jedem Medienwechsel automatisch den cache upgedatet wird.
Aber deine Anmerkung, dass der NAND geschont wird, ist sehr gut. Ich dachte nur an die relative Nähe von Index und PXMLs pro Medium wegen dem Umstecken der Disks in andere Pandoras/Slots.Bestenfalls kann ich sogar beim Fuellen des Sticks auf meinem DesktopPC gleich noch den Cache erstellen lassen.