vielleicht kurz warum es nicht xml ist:
(erstmal, das auf XML umzustellen wäre keine große sache... *das* ist nicht das problem).
XML ist groß. pro service hat man, auch wenn man tags wie <s> <n> ... benutzt (woraufhin es am ende gennausowenig lesbar sein wird wie das jetzige von enigma), min. 6 * anzahl_tags (<s><n>ProSieben</n>...) bytes verlust. momentan sind die felder durch ':' bzw. '\n' getrennt.
XML ist flexibler. Das stimmt zwar, aber auch nur vom format her. um untereinander kompatibel zu bleiben müsste enigma alle vorherigen versionen ebenfalls verarbeiten können - einfacher wirds da auch nicht.
dann lieber einmal im jahr (öfter wars bisher wirklich nicht) das format "komplett" breaken.
(Ich weiss, ich schieb damit die arbeit auf die programmierer der settingseditoren, sorry, aber ich find bei einem settingseditor ists egal ob der nen paar hundert KB größer ist oder nicht - bei enigma ist das nen bisschen blöd. daher denk ich auch schmeissen wir den satcodx-support aus enigma wieder raus. der hat da nichts verloren. evtl. als plugin.)
also was ich sagen will:
ob ich in xml jetzt alle felder umdefiniert oder ein komplett neues format baue, kommt aufs gleiche raus. da hat XML keinen vorteil.
Einfacher zu parsen: ja, stimmt, aber der code um enigma-settings zu parsen (nicht das verarbeiten, das müsste man bei xml ja genauso) ist auch nicht mehr als nen sscanf.
für den Computer ist XML um einiges schwieriger zu parsen. das hat damals locker 10 sekunden gedauert, nur das parsen von astra-daten. das ist mir erlich gesagt etwas zu lange.
Wovon ich träume:
Ein Format, welches man nicht komplett in den ram laden muss.
Ein Format, was gut skaliert (es gibt leute, die haben ALLE satelliten im "umkreis" von >100° oder so gescannt)
Ein Format, was man native benutzen kann (also nicht groß "zusammenfassen" muss oder so. Es sollte 1:1 in den speciher geladen werden können bzw., wie gesagt, sogar direkt benutzt werden)
Ein Format, wo man nicht alles neu schreiben muss, wenn sich ein paar dinge ändern. Auch wenn ein Name länger wird. Oder eine PID dazukommt.
eigentlich sind textdateien an sich ungünstig.
Mindestansprüche die ich stelle:
- Unlimitert (oder bis 255 zeichen meinetwegen) UTF-8-Kodierte Namen für Kanäle, Bouquets, Beschreibungen
- Speicherung von gecachten PIDs
- Namespace/ONID/TSID/SID etc. DVB-sinnvoll
- schnell zu parsen
- schnell zu schreiben
- für dritte zu verstehen (nach erklärung
gerade letzteres ist mir wichtig damit Settingseditoren auch damit umgehen können.
WENN also jemand
- ein binärformat entwickelt, was alle anforderungen sowie möglichst viele meiner wünsche erfüllt (ein paar stichwörter auf was man achten muss: fragmentierung, indexe/hashe, ...)
- dazu eine C- oder C++-library, die ohne externe dependencies (ausser Ansi-C++-kram und evtl. stl) das format schnell und gut bearbeiten kann
- und das alles getestet ist und funktioniert
dann übernehm ich sowas *sehr* gerne.
Ich hab nur momentan nicht die Zeit / Lust / Notwendigkeit sowas zu entwickeln.
, source?