PXML Format aktualisiert


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
46
Location
Ingolstadt
Ich habe die Definition des PXML-Formates ein wenig aktualisiert.
Sie ist nun XML-konform und hat ein paar weitere Funktionen mit integriert.

Für Fragen oder Ideen einfach hier posten :)

Download: PXML v1.2
 
EDIT: weiter unten hab ich diese ganzen Kommentare nochmals auf Deutsch übersetzt und noch etwas weitergespunnen.

okay, ich hatte sie zuerst in englisch ausformuliert, und da die faulheit obsiegt, werd ich sie nur auf Wunsch hin übersetzen:
  • <description> should mention explicitely default lang. is english.
    you describe 2 elements: <description> and <description lange=...>. but it's just the same element once with explicitely overridden lang. make it optional and if used that at least one entry should be "en" (empty -> default), any multiple listing of a language is ignored (first one taken) and if there is no "english" description the first in the list is taken
  • i propose an overview like:
    WHAT req/opt description
    element y (filled if the content is used, if empty, the "<../>" form is preferred)
    attrib1 y attrib spec
    attrib2 y attrib spec
    and a column with a defaultvalue for optional attributes
    you might even think about using shortcuts or short names to strip down the xml, requiring slightly less performance for future mass .pxml processing on big SD cards (okay performance should not be an issue, but just in case)
    XML requires each tag to consist of a opening and closing tag. there are no "standalone"
    tags as in HTML (e.g. <br> or <p>), so listing "<title>" instead of "<title></title>" is enough if the description tells that this element has no content.
  • <icon> misses details
    Should support different picture sizes if we support a generic GUI support. I suggest a naming schema e.g. "starcraft" -> the GUI must check for any starcraft-\d\d\d?\.(png|jpg|jpeg)
    the 2 or 3 digits would be 16/32/48/64/128, the size of the image (16x16 32x32 48x48(?) 64x64 128x128(?))
    support png, jpg (jpeg and jpeg2000), avoid any gif/tiff/bmp or similar outdated formats support. (at least tell the people to prefer those efficient formats) Try to use multiples of 16 or at least 8, which is the block size of jpegs and easier to handle in big counts in memory. also scaling is simpler. of course a single picture is enough, because GUIs would scale them up/down
    you can also support vector-formats, but the GUIs should avoid them or make them optional. If anybody wants super-cute menus, he can have it, but i prefer speed. Just take care of it in the pxml definition. can be implemented anytime later...
  • catlangs.xml requires information about case sensitivity
    i would use: case insensitve on matching the "category" and if a match was found the case from catlangs.xml is used in the GUI.
  • PXML (name): ambiguous choice?
    it says "pandora" and "in xml format". Any further config file for the pandora which uses xml fits the same criterias. to differ those xml files their extensions should say something about their usage, not just "it's an xml on a pandora".
    suggestion: Example: "PPPP" (Pandora Program Pack Paraphrase)
    or "PPPCF" (Pand Prog Pack Configuratio File)
    Tells just what it is about, no point about adding "xml" to the extension.
    use 4+ letters extensions by purpose to avoid clashes with existing 3 letters file format extensions
  • wording: you mixed up country/language/localization
    you definitely do not "localize" the titles, you just set the language. internationalization requires date formats, currency, numbers, ...
  • beside: make sure the xml parser is bufferoverflow secure because this would be the most obvious target for malware attacks.
  • Define GUI
    * GUI for the Pandora to start apps (i guess so)
    * GUI for emulators to start emulated apps
    Because you are programming as well emulators for the pandora you should state clearly that pxml files are for general GUIs, not for "application internal GUIs like in the emulators"
 
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.
Der Cache koennte auch eine unique ID pro Eintrag generieren, die in Konfigurationsdateien der GUIs oder was auch immer referenziert werden kann fuer detailierte Einstellungen wie z.B. einer manuellen Reihenfolge im GUI.
Genauso koennte eine Konfigurationsdatei im Root jedes Medium neben dem Cache existieren und detailierte Einstellungen zu den referenzierten IDs ermoeglichen. z.B. die Reihenfolge.

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.

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?
 
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.
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:
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.
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.
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?
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.

Zu deinem Beitrag vor diesem: Sorry, ich habe das Lesen nach dem ersten Punkt abgebrochen. Ich finde es nicht schlimm, wenn mal ein Beitrag auf Englisch ist, aber richtige englische Sätze mit Punkt und Komma wären schon nicht schlecht gewesen. Nichts gegen ein paar Fehler. Fehler passieren jedem, aber es wäre echt toll, wenn zumindest die Grammatik so grob stimmen würde, sonst ist das echt mühsam, das zu entziffern. Das sollte jetzt kein Angriff sein.
 
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.
natürlich, wurde auch so in den anforderungen beschrieben. dem habe ich auch nirgends im beitrag wiedersprochen
Ein Cache könnte bei Geschwindigkeitsproblemen echt eine ganz gute Lösung 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 redundanz
  • keine verzögerung beim bedienen der gui weil sie vor dem aufbau mal schnell alle medien scannt. und ich rede hier von bruchteilen von sekunden. ein gui, das auch nur 2/10 sekunden zögert vor dem aufbau, das fühlt sich einfach langsamer an.
  • zentralisieren des "suchens". wenn die gui frei ersetzt werden kann, müsste jede die suchfunktionalität implementieren. macht keinen sinn. schlimmstenfalls würde jede noch einen eigenen cache iplementieren...
  • keine batterieverschwendung duch wiederholtes "automatisches" suchen.
es wird immer einen geben, der in seiner gui implementation etwas übersieht und die suchfunktion zu oft aufgerufen wird. also lieber gleich einen cache zur verfügung stellen und dem benutzer eine option in die hand geben um die häufigkeit zu steuern.
ich selber würde z.b. sicher immer auf "manueller start" umschalten und wüsste, dass die pandora nie auf die idee kommt seinen cache upzudaten, nur weil ich die sd karte wieder einstecke ohne, dass neue software drauf wäre.
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.
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.
denn es wird sicher alternative guis für die pandora geben. darum diskutiere ich im ersten beitrag auch die nutzung von icons in verschiedenen auflösungen, damit jedes gui ein passendes findet. die einen werden lieber viele elemente auf einmal sehen wollen, während andere lieber grosse icons haben möchten, weil sie es schön finden oder weil sie es per touchscreen nutzen wollen.
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 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.

da es nur um die referenzierung in konfigurationsdateien geht, würde es sogar genügen, wenn beim cache-aufbau irgend ein hash-wert generiert wird. im moment des cache-aufbaus sind ja alle einträge bekannt, da können auch nur aufsteigende nummern vergeben werden. dass sich das nicht mit applikationen auf anderen medien beisst, kann in den referenzen die applikationsnummer und die medien-nummer (hat eine sd karte nicht hardwaremässig eine eindeutige nummer?) nutzen. das ganze scheitert aber wenn applikationen auf einem medium verschoben werden. denn beim neuaufbau des caches wird die applikation als "neu" eingestuft und kriegt eine andere ID.
darum ist es dann doch besser dem ersteller der software das generieren einer UUID zuzumuten und sie im PXML einzubetten.
alles eine frage der abwägung, eine "optimale" lösung gibt es nicht.

der cache sollte zumindest dies enthalten:
liste mit relativen pfaden (zum root des mediums) aller pxml aller applikationen auf dem medium, jeweils mit einer ID (bevorzugt generierte UUID). das könnte sogar ein simples shellskript (find,sed) erledigen. der output könnte dann eine simple tab delimited textdatei sein. textdatei deswegen, weil wegen der wenigen informationen xml kaum vorteile bringt und nicht jedes gui werkzeug sich mit xml parsing rumschlagen sollte. und ich kann die unix stringutils nutzen um das cache zu durchsuchen, ausgabe formatieren, usw.
 
habe das Lesen nach dem ersten Punkt abgebrochen. ... aber richtige englische Sätze mit Punkt und Komma wären schon nicht schlecht gewesen.
dies ist ein diskussionsforum um die pandora zu optimieren, nicht um ein forum voller literarischer höhepunkte zu erschaffen.
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...
zumindest die Grammatik so grob stimmen würde, sonst ist das echt mühsam, das zu entziffern. Das sollte jetzt kein Angriff sein.
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.

um aber zu vermeiden, dass andere den beitrag nicht lesen, weil ihnen die form wichtiger ist, hier eine übersetzung.
  • <description> sollte explizit anmerken, dass lang="english" default ist.
    Du beschreibst 2 Elemente: <description> und <description lang=...>. Dabei ist's nur eines mal mit explizitem Setzen des Attributes "lang" und einmal mit default (lang="english"). Einfacher wäre ein Element, das Attribut optional und Default "en". Das Element muss dann mindestens vorkommen. Falls zwei Einträge mit derselben Sprache existieren wird nur der erste berücksichtigt. Per default wird der englische angezeigt. Falls kein solcher vorhanden, wird die zuerst gelistete Beschreibung angezeigt. Sollte eindeutig sein, oder?
  • ich schlage foglende Form vor:
    (Kann hier leider keine Tabelen erstellen, daher stellt das || eine Zellentrennung dar)
    Element/Attribut || Optional || Beschreibung || Default (für attribute)
    element 1 || n || (Falls Inhalt wichtig, hier beschrieben, falls nicht, "<../>" Schreibweise bevorzugt)
    attribut 1 || j || Attributbeschreibung || z.B. "en"
    attribut 2 || j || Attributbeschreibung
    Man könnte auch die Namen kürzen für eine vermutlich zu vernachlässigende Beschleunigung der Verarbeitung. Nur in Anbetracht späterer 64gb SD Karten voll mit Software... Bei einem Cache wie vorher vorgeschlagen ist dies aber nicht mehr so wichtig.
  • Es genügt z.B. "<title>" statt "<title></title>" zu schreiben, im Gegensatz zu HTML verlangt XML immer ein Paar von Tags (<..>..</..>). Und in der Beschreibung erwähnen, dass wenn der Inhalt unwichtig ist, die </...> Schreibweise bevorzugt wird. Zu verlangen, dass der Nutzer immer </..> schreibt anstatt <..></..> macht zwar den Parser einfacher, bricht aber mit XML. Yep, ich hasse diese Schwammigkeit von XML auch, aber leider ist es schon so im Standard.
  • <icon> ist zu ungenau beschrieben
    Nur auf ein Bild zu veweisen macht es nicht möglich verschiedene Auflösungen anzubieten für die verschiedenen GUIs.
    Lieber ein naming schema wie z.B. NAME-\d\d\d?.EXT. Wobei <icon>starcraft</icon>, dann auf starcraft-16.png, starcraft-128.jpg usw. zutrifft. Die 16 und 128 sind die Bildformate. Also z.B. 16x16 32x32 48x48(?) 64x64 128x128(?), Mehrfache von 8 oder 16 sind besser für JPEG Komprimierung, einfacher im Memory zu cachen und einfacher zu Skalieren (Nicht zufällig werden Icons auch in den genannten Formaten auf anderen Systemen genutzt). Und die Endung entspricht einer der bekannten Bildformate. Am besten noch die Bildformate vorschlagen (PNG für kleinere, JPG/JPEG2000 für grössere), damit niemand auf die Idee kommt Platz zu verschwenden mit BMP/TIF/GIFs. Ich würd sogar mit Absicht die Formate limitieren und eine Reihenfolge für die Eindeutigkeit definieren (starcraft-32.png wird einem starcraft-32.jpg vorgezogen).
    Falls nicht alle Bildformate vorhanden, kann das Icon immer noch aus einem kleineren/grösseren skaliert werden.
    Man könnte auch schon Vektorformate nicht ausschliessen, für spätere noch "aufgemotztere" GUIs.
    Für den Anfang reicht aber nur 16x16 oder 32x32 und png (oder auch zusätzlich jpeg) zu nutzen, kann immer noch später ergänzt werden. Wenn die Spezifikation aber schon vorher feststeht, können die Entwickler schon jetzt grössere Icons schon mal mitliefern.
  • catlangs.xml benötigt Ausführungen zu case sensitivity
    Ich schlage vor, dass die Kategorie case insensitive verglichen wird und im GUI die Schreibweise aus catlangs.xml angezeigt wird.
  • PXML (name): zuwenig eindeutiger Name.
    Der Name sagt aus, dass es eine Datei für den Pandora und das Format XML ist. Jede zukünftig definierte Konfigurationsdateien in XML treffen aber auch auf die Kriterien "pandora spezifisch" und "in XML" zu. Die Extension sagt schlichtwegs nichts über die Verwendung der Datei. Um solchen Wirrwar zu vermeiden würde ich daher die Endung anhand der "Verwendung" benennen und mindestens 4 Zeichen verwenden um Kollisionen mit bestehenden Extensions zu vermeiden (bei 3 Zeichen zu wahrscheinlich), z.B. "PPPP" (Pandora Program Pack Paraphrase) oder "PPPCF" (Pand Prog Pack Configuratio File) oder oder...
    Das sagt explizit aus was es ist.
  • Im Text wird Land/Sprache/Lokalisierung vermischt.
    Die Titel sind mehrsprachig ausgelegt, aber nicht "lokalisiert" bzw. "internationalisiert". Dies umfasst auch Datums-, Zahlen-, Geldformate und weitere Verrücktheiten.
  • Der XML Parser sollte sehr sicher vor bufferoverflows sein, denn das Verbreiten von Schadsoftware über manipulierte PXML Dateien bietet sich hier geradezu an... Sobald die Pandora eine genug grosse Verbreitung findet. :D
  • Definiere GUI explizit.
    GUI für das Starten von Applikationen auf der Pandora, nicht GUIs für Emulatoren um emulierte Applikationen zu starten. Da Ihr auch Emulatoren mitprogrammiert und mitausliefern werdet, könnte das jemand verwechseln.

Und wenn ich schon bei Emulatoren bin noch kurz offtopic: Ich hoffe, die Emulatoren werden auch (hardware)Skalierung auf 800x480 beherrschen. bei einem 4.3 Zoll Bildschirm möchte ich lieber eine Option zum Ausnutzen des Platzes, was den aspect ration zwar verbiegt, dafür aber das Bild grösser darstellt.
Zugleich auch ein "blurring" der Darstellung, um ein TV-Bild nachzuahmen (drum sahen die Games damals noch gut aus). Dann macht auch die falsche aspect ratio nicht mehr viel aus.
Natürlich dürfen andere ruhig auf ihrem korrekten aspect ratio bestehen und/oder im freien Bereich Emulator-status-info anzeigen. Aber das brauch ich nicht ständig beim Zocken.
(sobald ich den richtigen Thread finde, füge ich diesen Kommentar auch dort ein)
 
Ausführungen zum Cache

<r>Der Cache würde nur die ID und den Pfad enthalten, denn jedes GUI würde sowieso eigene spezifische Informationen aus den Beschreibungen beziehen (ist ja in der Spez explizit erlaubt). Daher nur auf die PXMLs verweisen und jedes GUI kann dann selber in den PXML die Details nachlesen und die richtigen Icons herauspicken. Danach würde das GUI sowieso zur Laufzeit die Infos im Speicher halten und könnte z.B. auf den Zeitstempel der cache Datei auf jedem Medium achten um "Aktualisierungen" mitzubekommen.<br/>
<B><s></s> Klar wenn das GUI wieder abgeschossen und wieder gestartet wird von Applikationen (wurde von Craig selber erwähnt), um die volle Pandora Performance zu nutzen, muss es die Infos wieder neu einlesen. Gerade hier wird dann aber der cache pro Medium schon mal das Suchen ersparen!!! Wenn dann das GUI selber seine letzten Erkenntnisse auch wieder persistent cached, wird das GUI auch bei einem Neustart wunderbar responsive <e></e></B> <E>:lol:</E></r>
 
Die Möglichkeit Funktionen für Dateitypen zu registrieren erlaubt zwar einfach "objektorientierte/dokumentenorientierte" GUIs, aber gerade bei vielen Emulatoren ist schnell Schluss. Hier wird (bestes Beispiel ist der Amiga) nämlich zum Starten das Image, die Applikation UND EINE KONFIGURATION benötigt. Es reicht nicht den Emulator mit dem Diskimage zu starten. Man müsste eher eine Konfiguration (Einstellungen+Diskimages) starten.
Wenn ich also gerne in meinem GUI ein Game als direkten Link mit Icon hätte, das aber in einer spezifischen Konfiguration starten soll, wie mach ich das?
Z.B.
  • Konfigurationen werden als einzelne Dateien im Dateisystem abgelegt. Ein Link darauf genügt. Userfriendly, aber ob ich soviele kleine Dateien haben möchte??
  • Link auf einen Emulator und explizite Parameterliste im Link einfügen (falls der Emulator solche kennt. Weniger Userfriendly
Was hat sich das Pandorateam da für Konzepte ausgedacht?
Die Beantwortung und die Definition von "Links" in GUIs ist für PXML eigentlich offtopic, sollte aber auch in einer Schicht unterhalb der GUIs definiert sein, dann können "Links" in allen GUIs wiederverwendet werden.
Die Lösung könnte man bei Gnome/KDE/fvwm/icewm/... abgucken.
 
various informations
can be used to save configuration options from different GUIs (by adding their own config sections).
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:
 
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.
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.
Dies ermöglicht es die Konfigurationen auf der Pandora zu halten, anstatt verstreut auf den Sticks. Wenn ich dieselbe App auf einer anderen SD disk habe, gilt die Konfiguration immer noch. Die PXML der App beizulegen verstehe ich, aber die Usersettings beizulegen? Macht nur Sinn, wenn ich beim Bespielen der SD disk meine Konfigurationswünsche gleich miteintrage möchte bevor ich das Teil in die Pandora einlege. Mit UUIDs müssen die User-overrides nicht gleich mit im Verzeichnis beiliegen. Oder ich möchte unbedingt einen anderen Menüaufbau haben je nach eingelegter disk??

Mir kommts vor als wenn dieser Teil der Datenhaltung für Konfigurationen und User-settings etwas wenig durchdacht/ausformuliert/festgelegt wäre?? Vermutlich habt ihrs durchdacht aber zuwenig kommuniziert? Oder ich hab das Forum unzureichend durchsucht??
 
PandoraSuechtig said:
habe das Lesen nach dem ersten Punkt abgebrochen. ... aber richtige englische Sätze mit Punkt und Komma wären schon nicht schlecht gewesen.
dies ist ein diskussionsforum um die pandora zu optimieren, nicht um ein forum voller literarischer höhepunkte zu erschaffen.
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...
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.
zumindest die Grammatik so grob stimmen würde, sonst ist das echt mühsam, das zu entziffern. Das sollte jetzt kein Angriff sein.
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.

Es geht nicht mal um Tippfehler (die können passieren, wobei ich trotzdem der Meinung bin, dass man sich wenigstens ein bisschen Mühe beim Schreiben geben sollte - andere geben sich ja auch Mühe und lesen das Geschriebene), aber gerade der englische Text war alles andere als gut lesbar, eben weil die Sätze teilweise völlig ungrammatisch waren.
Nur mal als Beispiel - das hier...
"make it optional and if used that at least one entry should be "en" (empty -> default), any multiple listing of a language is ignored (first one taken) and if there is no "english" description the first in the list is taken"

...ist kein korrekter Satz im Englischen. Nach mehrmaligem Lesen habe ich eine Ahnung gehabt, was gemeint sein könnte, aber das kostet Zeit. Wie gesagt, es geht nicht darum, das man keine Fehler machen darf, aber die Einstellung, dass man sich, weil es "bloß ein Forum ist", keine Mühe geben braucht, finde ich nicht gut.

Jetzt aber mal etwas zum eigentlichen Inhalt:

Ich denke wenn man einen eindeutigen Identifikator für jede Software haben möchte, ist eine UUID schon die beste Wahl - wegen dem nicht vorhandenen Verwaltungsaufwand. UUIDs haben sich an anderen Stellen ja schon oft bewährt und die Chance einer Kollision ist verschwindend gering.

Was die Tags mit und ohne lang-Parameter angeht: Natürlich sollte das Tag ohne den Parameter identisch behandelt werden, wie das Tag mit Parameter und Default-Sprache (Englisch in diesem Fall). Alles andere wäre wirklich sinnlos und auch nicht im Sinne von XML.
Wenn es eine DTD zu PXML gibt (existiert eine?), kann man dort ja genau nachvollziehen, wie es wirklich gemeint ist und man könnte damit natürlich auch überprüfen, ob eine Datei ein gültiges PXML-Dokument ist. In dem PDF war dazu leider nichts zu finden.

Noch mal zum Caching: Ich habe das schon so gemeint, wie ich es geschrieben hatte: 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. 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).
 
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 :)
 
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 :)
Genau so hatte ich mir das auch gedacht!
 
Wenn es eine DTD zu PXML gibt (existiert eine?), kann man dort ja genau nachvollziehen, wie es wirklich gemeint ist
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.
könnte damit natürlich auch überprüfen, ob eine Datei ein gültiges PXML-Dokument 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.

Gute Wortwahl mit Indexierung! Meine Cachingausführungen gingen im Grunde wirklich auf eine Indexierung hinaus. Darum nennen ich das von nun an Indexierung!
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.
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.
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).
Die Suche in die GUIs selber zu verlegen halte ich für den falschen Weg. Das führ ich jetz etwas aus:

Anmerkungen
  • Eine Zentrale Lösung (als library oder als Hintergrundprozess) vermeidet nicht nur das jeweilige Neuerfinden des Rades, sondern auch die Anpassung aller Räder (GUIs), wenn später die Anforderungen, betreffs was gesucht oder wo gesucht werden soll, ändert.
  • Ich erwarte, dass später nicht nur die GUIs, sondern auch andere Applikationen die Medien durchsuchen werden. Sollten mehrere Applikationen zugleich suchen wollen, hast du damit konkurrierende (Such)Lesezugriffe.
  • Ein Index spart einfach Zeit (da GUIs oder sonstige zugreifende Applikationen nicht jedesmal einen vollständigen Suchvorgang starten) und jemand muss ihn erstellen. Wenn nun einige Applikationen parallel anfangen zu Suchen und den Index zu schreiben... Es muss eine zentrale Stelle geben, die für das Erstellen des Index zuständig ist.
  • Der Index zeigt nur die Orte wo PXML Dateien zu finden sind. Die Icons, Dateitypverknüpfungen und alles andere müssen sowieso von jeder Applikation selber gelesen werden und die/das Applikation/GUI müssen diese Infos cachen (jetzt ist wirklich cachen gemeint) um "responsive" zu bleiben.

Die Frage ist die Synchronisation der Indexerstellung und des Zugriffes um folgende Situationen zu vermeiden
  • Wenn die Applikationen einzeln suchen, würden sie auch einzeln Indexe erstellen. Sich dabei aber nicht konkurrieren beim Schreiben.
  • Applikation wartet auf Ende der Indexerstellung
  • Applikation greift auf Index zu, der gerade erstellt wird (Die Suche sollte jedes Resultat sofort eintragen,
    um nicht noch Memory zu verschwenden. Dadurch ist der Index aber nicht vollständig bis die Suche fertig ist).

Mögliche Lösungen
  • Beim Einlegen legt ein Indexierungsservice/job/... los und schreibt die Funde sofort. Eine Applikation kann auf dem bestehenden Index seine Anzeige aufbauen und bei Änderungen (Datei ändert ihren Zeitstempel bei einem Schreibzugriff) die Anzeige anpassen. Das entspricht ziemlich genau der
    parallele Ausführung von PXML-Dateiverarbeitung und Anzeige der GUI
  • Ein Semaphor zeigt an, dass der Indexbau "in Arbeit" ist. Eine "vorsichtige" Applikation oder eine die auf einem konsistenten Zustand bestehen muss, kann einfach auf den Semaphor warten. Ein vorzeitiges Ausstecken der SD sollte keine Probleme bereiten, denn entweder liegt der Semaphor sowieso im NAND oder beim nächsten Einstecken wird dieser zuerst gelöscht. Wenn aber mehrere Applikationen oder GUIs diesen setzen/löschen können, weil jeder von ihnen am Index rumfummelt, weiss nun keiner mehr ob jemand schon am Index rumschraubt oder ob nur der Semaphor nicht gelöscht wurde.
  • Der bestehende Index wird zum "letzten gültigen" umbenannt, während der aktuelle aufgebaut wird. Eine Applikation/GUI kann den letzten anzeigen und refreshen sobald der neue endgültig fertig ist. Wär schon cool wenn das GUI die Elemente im Kontextemenü einer Datei als "volatil/unsicher" markieren würde (weil das Medium auf dem die Applikation wäre noch nicht wieder neu durchsucht wurde) oder ein Icon markieren (bis die Applikation wiedergefunden wurde oder sie verschwindet, da nicht mehr gefunden). Die Anzeige kann sich sogar noch ändern, weil dann evtl. andere Infos in den wiedergefundenen PXMLs stehen.
    z.B. Stecke ich die SD wieder ein, die vorher darauf gefundenen Apps tauchen wieder auf im GUI (markiert, da noch gesucht wird) und ein Icon (eine Applikation) wäre mit "Turrcan" angeschrieben (das steht im GUI-eignen Cache für diese UUID, die jetzt im "dirty index" auf der SD auftaucht) und nach Beendigung der Suche, sobald die App wiedergefunden wurde, steht plötzlich "Turrican" und das Icon sieht anders aus.
  • Ein Index wird nur dann immer erstellt wenn keiner besteht. Ein Refresh könnte explizit im GUI ausgelöst werden (wobei wiederum der unterliegende Service angestossen werden könnte, statt dass das GUI das selber erledigt) oder je nach Einstellung.
  • Das Verhalten der Indexierung (immer, manuel) kann dann zentral eingestellt werden und hängt nicht von der Gnade eines jeden GUI-Progammierers ab ob er diese zur Verfügung stellt.

Meine Schlussfolgerungen:
  • Um eine "flüssige" Bedienung der Pandora ungeachtet der SD disks Grössen und in jeder Situtation zu gewährleisten, wird man kaum um einen Index herumkommen.
  • Das Schreiben des Index sollte zentral erfolgen (da mehr als nur das GUI diesen nutzen könnte), womit man auch gleich die Suche zentral erledigen kann.
  • Um diese Dynamik im GUI zu haben, wird eine Kommunikation mit dem System unbedingt nötig sein. Zumindest eine Benachrichtigung wenn die SD gewechselt wird und dann mit dem Suchen loslegen. Da kann man effizienter die Suche dem System überlassen und das API ausweiten.
  • Eine GUI-interne Optimierung durch paralleles Suchen und Aufbauen des GUI kann man genauso gut auch mit einem zentralen Service bzw. einer vom System erstellten Indexdatei verwirklichen. Ob dieser Service als ein Hintergrundprozess oder wie auch immer implementiert ist, ist eine andere Frage. Grundsätzlich sollte er aber nicht Bestandteil der GUI selber sein.
  • Die Applikationen können sich nicht ins Gehege kommen beim Indexerstellen.
  • Der Index kann auch für andere Applikationen als nur GUIs nützlich sein.

Die <filetype> Geschichte finde ich etwas ambitiös, denn zur Laufzeit durch Ein- und Ausstecken einer SD Disk die Verknüpfungen zu Dateitypen zu ändern mit zusätzlicher Durchforstung jedes neuen Mediums, das erfordert auch einige Dynamik im GUI. Ich hätte lieber eine frühe Version, die zumindest funktioniert und notfalls schon mal leicht Zögern kann beim Einstecken (lieber aber eine Einstellung mitliefert wo ich "nur manuelles Triggern der Suche" einstellen kann), als eine bugfreie, perfekt laufende, schnell reagierende irgendwann im 3. Quartal 2009...
 
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.
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.
Ich rede davon, dass wir eine 64gb SD mit abertausenden von Verzeichnissen durchsuchen um einige Dateien darauf zu finden. Das Problem liegt darin die Suche über die gesamte "Verzeichnisstruktur" einzudämmen.
Wenn ich auf meiner 500gb Platte Dateien suche und er durch alle Verzeichnisse (Mein Liebling ist der cygwin-folder) wühlt, warte ich ziemlich lange... Aber aus einer 20mb Datei eine primitive Checksumme zu erstellen, das geht in null komma nix.
Und kommt mir bitte nicht mit dem diskcache. Bei 256mb Speicher brauch ichs nicht, dass er mir paar mb Verzeichnisstruktur cached, die er lesen musste, nur damit später ein rescan schneller funktioniert. Und sobald ich die SD rausnehme und wieder einstecke (das ist ja der use-case), ist der diskcache sowieso wieder weg!
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.
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.
Und die GUI sollte natürlich auch einstellbar sein, dass sie nur auf Wunsch neu scannt
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.
Aber, dass kein Index besteht und bei jedem Einstecken der SD der Scan wieder anläuft... Um Software zu entwickeln müsst ich dann die Soft auf einen einzelnen leeren Stick schmeissen, damits immer schnell geht. Dann leg ich wieder meinen normalen Stick ein und fluche weil, das GUI die Infos zu diesem Stick bereits wieder weggeschmissen hat und der Scan dauert...
Okay, klar, ich kann auch beide SD-slots nutzen... Hoffentlich ist der Rescan pro slot/drive möglich..
Genausowenig hab ich Lust darauf, dass jede Applikation die nach PXMLs sucht, einen Index mitsamt Pfaden zu jeder App dupliziert und alles je gefundene cached mit verknüpfung zur SD-Nummer. Bei 512MB NAND nicht gerad erfreulich.

Zumindest die UUID wär noch sehr wichtig, damit die GUIs ihre Konfigurationen relativ zu dieser speichern. Siehe dazu meine Anmerkung zum Verschieben von Apps. Der Pfad ändert sich und das GUI erkennt die App nicht mehr, dropped alle Einstellungen.

Spätestens sobald erste (nicht GUIs) Apps erscheinen, die nach Apps suchen, wird man einen Index vermissen...

Klar, ich spiele jetzt Kassandra für "Extremfälle", aber ich bin halt sicher ich persönlich werd mal nen abgefüllten 64gb stick einstecken und dann daran zurückdenken... Hoffentlich im Irrtum und mit einem Lächeln... :|
 
PandoraSuechtig said:
Wenn es eine DTD zu PXML gibt (existiert eine?), kann man dort ja genau nachvollziehen, wie es wirklich gemeint ist
Du meintest XSD? DTD ist veraltet.
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?!
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.
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.
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.
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.
Dazu kommt, dass der Prozess auch die Akkulaufzeit reduziert, wenn der permanent im Hintergrund läuft.
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.
 
XSD ist ein Vorschlag des W3C, DTD ist Teil des XML-Standards.
Aha, wieder was gelernt.
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
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:
Jeder Prozess verbraucht Ressourcen. ..., zum Anderen CPU-Zeit.
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.
Selber schuld wer ihn als pollenden Prozess hackt...
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 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.

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.
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.
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.
Dazu kommt, dass der Prozess auch die Akkulaufzeit reduziert, wenn der permanent im Hintergrund läuft.
sleep state... siehe oben.
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.
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.

Aber immer noch lieber als dass mehrere Applikationen parallel ihre Indices führen und zugleich die SD scannen...
Muss dich enttäuschen, bin immer noch vom zentralen Indexierungsservice überzeugt ^_^

Und um jetzt in die Offensive zu gehen: Wie würdest du ein "Veto"-System mit der einfachen Lösung einrichten, so dass eine Applikation das Scannen eines Mediums aufschieben oder vorübergehend ganz verbieten kann? Und Wie würde man den Extraspeicherverbrauch/Extrabatterieverbrauch, der entsteht wenn jede App selber indexiert, vermeiden?

Zugegeben, wenn es sich rausstellt, dass auch ein Scan eines grossen Mediums verkraftbar ist (oder die Apps nur in einem Verzeichnis liegen dürfen(der natürlich Unterverzeichnisse enthalten darf), was den ganzen Aufwand extrem reduzieren kann), dann wäre ein volatiles Halten der Information auch ok, weil dadurch der NAND Flash nicht belastet wird und der Index sowieso schnell wieder da ist. Ein zentraler Indexierer würde dann zwar immer noch Memory und Batterien sparen, aber das Vermeiden des Wartens war meine Hauptsorge. Hier lob ich mal kurz das Feature, dass die Pandora nocht bootfähig ist, auch wenn der NAND schon im Speicherhimmel ist :D
 
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:
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.
Jeder Prozess verbraucht Ressourcen. ..., zum Anderen CPU-Zeit.
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.
Selber schuld wer ihn als pollenden Prozess hackt...
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.
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 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.
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.
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.
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.
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.
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.
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.
Dazu kommt, dass der Prozess auch die Akkulaufzeit reduziert, wenn der permanent im Hintergrund läuft.
sleep state... siehe oben.
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.
Um das ganze vielleicht etwas abzukürzen, schreibe ich einfach kurz, wie ich es für sinnvoll halten würde:
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. 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.
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.
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.
 
zum XML: Um das gings mir ja auch. Das ganze "XML" konformer zu beschreiben, nicht extra die Varianten, sondern nur das Attribut als Optional deklarieren reicht.
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.
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.
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.
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.
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.
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.
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, da
  • Speicherverschwenderischer.
  • Unterschiedliche Implementationen (Ein App findet nicht dieselben PXMLs wie eine andere oder interpretiert sie anders).
  • Das Abschiessen der GUI reicht nicht mehr, denn jede andere App kann immer noch nach Lust und Laune auf den Medien rumwühlen.
  • Konkurrente Lesezugriffe auftreten, wenn mehr als eine App zugleich suchen.
  • Verwirrung des Users, wenn Apps unterschiedliche Ergebnisse zeigen, da die eine noch am Suchen ist.
  • Unterschiedliche Optionen in den Apps zum "Suchen" verwirren den User.
  • Warum sollte ich in jeder App das Suchen wiederum einzeln anstossen? Warum nicht zentral und jede App kriegts mit. Wieder nicht Userfriendly.
  • Jede verbesserte Implementierung des Suchvorgangs müsste in jeder Applikation einzeln nachgeführt werden.
  • Die Spezifikation wo die Apps zu finden sind kann sich ändern und nur der "Service" müsste angepasst werden, schon sind alle uptodate. Wenns in jeder App einzeln drinsteckt, kansnt solche Änderungen vergessen.
  • Es gibt Erweiterungen zu Linux-Windowmanagern die man als "Docks/Tabs/..." usw. starten kann und sie beinhalten v.a. "Shortcuts" zu Programmen. Als Beispiel sei eine solche App genannt, die den "Dock" des MacOSX nachahmt. Damit sie die Apps starten können, müssen sie diese kennen/finden. Das kann das GUI machen? Klar, dann gibts auch hier wieder pro GUI ein proprietäres API und diese GUI-Erweiterungen laufen dann nur jeweils auf diesem oder jenem GUI... Wenns aber ein Teil des Betriebssystems ist, z.B. ein Call "startApplication(UUID app)" und Möglichkeiten den Index abzufragen, kann ich locker ein grafisches Dock implementieren, das beliebig apps starten kann und muss nur die grafische Ausgabe je nach GUI anpassen. Und ja, das wirds auch auf der Pandora geben, gabs schon auf meinem 486 mit Suse, und der verkraftete das locker...
Welche Programme auch einen Index bräuchten?
  • Wenn ich eine simple bash laufen lasse, wie starte ich dann ein Programm, dass nicht im Pfad ist, sondern dem System nur über ein PXML bekannt?? Wenns einen zentralen Index gibt, hilft ein kleines Kommandozeilenapp "runApp <title/macro>". Andernfalls wäre so ein "runApp/panRun/..." auch wieder ein Kandidat der Disks durchsucht und v.a. nicht über ein "GUI-API" laufen sollte. Die Shell läuft ja auch ohne GUI.
  • Systeminfo tools, die alle installierten Pakete anzeigen
  • "Shells" die wiederum Apps oder zu Dateitypen registrierte Apps ausführen wollen. Damit meine ich schon vorher genannte "Dock"s aber auch z.B. eine simple App, die kurze Macros akzeptiert. Für selten genutze Pakete kann ich dann auch ein solches eintippen zum starten. Das entspricht dann auch weitestgehend dem ersten Beispiel mit der Shell.
  • Eine App die Programme aufgrund von Hotkeys startet?
  • Eine Wecker-app die zeitgesteuert andere Apps startet (ich möchte mich mit Musik wecken lassen). Wie soll ich ihm sagen was er starten soll? Expliziten Pfad?? Lieber aus einer Liste (aus dem Index erstellt) auswählen und er merkt sich die UUID.
  • Wenn ein Programm testet will ob ein anderes vorhanden ist, müsste es auch wieder selber suchen. Beispiel: Doom sucht nach weiteren WADs, die als zusätzliches Paket "installiert" sein können.
Und die Argumentation, dass die Programme die GUI nach dem Index abfragen könnten, greift nicht. Das wär dann so wie eine App für KDE und GNOME usw. anzupassen, weile jede ein anderes copy-paste API anbietet. Es werden auch auf der Pandora verschiedene GUIs entstehen und dann gibts den Wirrwarr wie bei KDE/GNOME, weil zuviel Basisfunktionalität in beiden unterschiedlich gehackt ist. Genau dies möchte ich mit dem Index vermeiden, dass alle Apps, die es benötigen darauf Zugriff haben und nicht "je nach laufendem GUI" mal funktionieren, mal nicht. V.a. ist der Index eine Funktionalität die unterhalb des GUI angesiedelt ist, siehe das Beispiel mit dem "runApp" um Applikationen auch von der Shell aus zu starten.
Auch wenn ich nicht zwei GUIs parallel laufen lasse, allein schon das Beenden einer GUI und das Starten einer anderen verzögert sich, wenn die neue GUI erneut die Disks durchsucht...
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.
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.
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.
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, 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...

Das entspricht auch genau meiner Forderung zumindest eine Einschränkung zu machen wo die Apps auf einem Medium sein dürfen, irgendein Standardverzeichnis, sonst muss entweder eine verschwenderische Komplettsuche her oder jedes GUI ist gezwungen die "Notlösung" anzubieten, dass der User selber den "Suchbaum" einschränken kann. Sowas sollte inhärent bzw. transparent gelöst sein, nicht dem Nutzer aufgebürdet werden. D.h. nicht, dass ich gegen das Anbieten der Einschränkung des Suchbereiches bin, sondern, dass dies ein Extra sein sollte, das man selten nutzt und schätzt und nicht dass daraus ein notwendiges Übel bei jedem Einlegen der disk wird, von der man weiss, dass sie zuviele Verzeichnisse enthält. Ich seh schon die forumsfragen "meine pandora scannt lahm, wie kann ich das beschleunigen?" - "bei GUI x unter x->y->z ein Verzeichnis eintragen und seine apps immer dorthalten, bei GUI y unter ...". Genausogut kann man schon jetzt ein Standardverzeichnis festlegen, dann stossen wir nicht so schnell auf dieses unnötige Problem. Ich brauch kein Windows-like System, dass ich an allen Ecken konfigurieren muss, bevors brauchbar läuft. Es sollte out of the box top laufen. Aber natürlich wirds auch hier wieder Fragen geben "Hab meine App auf die Disk kopiert, die Pandora findet sie nicht" - "oh, noobie, du musst sie ins Verzeichnis xxx stellen".
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.
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.
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.
Hatte ich das nicht schon im zweiten Beitrag so geschrieben? Siehe (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.
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):
Bestenfalls kann ich sogar beim Fuellen des Sticks auf meinem DesktopPC gleich noch den Cache erstellen lassen.
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.

Also wejp, hab den Fehdehandschuh wieder aufgenommen, freu mich schon auf deine Riposte :)
Mit jedem Beitrag werden unsere beiden Vorstellungen immer detailierter, egal welche schlussendlich implementiert wird (vermutlich deine, aber ich diskutier gerne).
 
Hab den Punkt schon oben angebracht, aber hier explizit als Frage an Evil Dragon:
Wenn die Pandora die Applikationen per PXML "installiert", dann funktioniert das wunderbar mit GUIs. Wenn ich aber so eine App von der Kommandozeile aus starten möchte... Fehlanzeige. Wenn hingegen ein zentraler Index pro Medium auf jedes PXML verweist, kann ein einfaches Kommanzeilentool geschrieben werden, dass diesen nutzt um Apps zu starten. z.B. mit einem "panRun <app>". Die App könnte dann mit dem Titel oder viel besser mit einem kurzen Alias referenziert werden (könnte auch an andern Stellen/Apps nützlich sein). z.B. "A" für den AmigaEmulator, "T2" für ein "Turrican 2" oder "Q3" für ein "Quake 3" :D .Dann bräuchte es aber noch irgendwo eine Datei mit Aliasen für die einzelnen Apps. Es genügt in dieser die Apps mit der UUID aus den Indices zu referenzieren. Dann können diese Aliaslisten sogar zwischen Usern ausgetauscht werden. Bitte nicht Aliase in PXMLs einbetten (bestenfalls zusätzlich als "hints" bzw. Fallbacks wenn sie nicht in der vom User definierten Aliasliste gefunden wurde), es geht ja um Userspezifische Konfiguration.
Vorteil? Ich kann Apps auch aus einer shell starten oder gar vermeiden in das GUI booten. Okay, bei einem ständigen Standby ist letzteres nicht realistisch, aber aus der Shell starten wär schon bequem. Kurz "panRUN Q3" eintippen und losballern :oops:
So kann ich auch eine eine Wecker-app erstellen, die zeitgesteuert andere Apps startet (ich möchte mich mit Musik wecken lassen). Wie soll ich ihm sagen was er starten soll? Expliziten Pfad zur PXML?? Lieber aus einer Liste (aus dem Index erstellt) auswählen und er merkt sich die UUID. Ohne Index ginge das nur, wenn diese App ein Teil des GUI selber sein soll. Nach euren Vorstellungen soll ja nur die GUI selber nach PXMLs suchen.

Habt ihr diesen Aspekt bedacht? Do you even care?? Es genügt mir schon, wenn die Idee mit einem zentralen Index durchkommt (schamloses lobbying) :wink: , so ein StarterApp kann immer noch später programmiert werden.

Und wie sieht das aus wenn ich Ubuntu oder was auch immer installiere, wie soll ich dann per PXML installierte Applikationen nutzen?? Ich schätze hier ist die klare Antwort "Gar nicht". Was mir auch genügt, denn ich würde mir kein fettes Ubuntu auf die arme kleine Pandora knallen. Das wär nur auf ner SD-card als nettes Gimmick for fun drauf und ich würds bestenfalls zum Beweis, dass es läuft anderen vorführen. Ansonsten hätte ich keine Verwendung dafür. :huh:
Bin da sowieso eher überzeugter Puppy-Linux-Fan, das läuft und bootet ein mehrfaches schneller auf einem alten P-II als Ubuntu auf einem aktuellen DualCore.... :wink:
 
Back
Top