Sinnvolle Skalierung für Statuswert (Dateigröße)?

[himitsu]

Moin Allerseids,

meine XML-Grundklassen können ja quasi XML-Dateien beliebiger Größen verarbeiten
> 16 EB direkt und seriell noch viel mehr
auch wenn soviel aktuell wohl nicht grad realistisch ist
und mein "Problem" liegt auch weit unter dieser Grenze.

Ich habe nun diese Callback-Prozedur
TXMLFileStatusEvent = Procedure(XML: TXMLFile; SType: TXMLFileStatus; State: Integer) of Object; und wie man an State sieht, ist sie auf 2 GB begrenzt (4 GB mit Cardinal).
Nun möchte ich dieses aber nicht auf 64 Bit aufweiten, da meißtens eh nur Werte mit maximal 32 Bit übergeben werden,

also dachte ich ich skaliere die größeren Werte (verarbeitete Datenmenge/Dateigröße).

Aus heutiger Sicht reicht wohl schon KB (also durch 1024) und man käme bis 2 TB (4 TB).

Aber was denkt ihr, könnte es die nächsten 5-10 Jahre auch schon zu wenig werden?
Und würde sich doch schon MB anbieten.
(verarbeitet würde dennoch mehr werden können, nur täte dann halt eventuell der Statuswert einen Überlauf bekommen können)

Die Festplatten werden ja minütlich größer.

[taaktaak]

Moin, Moin.
Ist das nicht ein wenig sehr weit in die Zukunft geschaut?
Vermutlich kennt in 10 Jahren kein Mensch mehr XML
(oder halt nur noch die OLDIES)

[himitsu]

Kennst du noch das 2000er-Problem?
Damals dachte man auch "Ach, der Computer setzt sich eh nie durch über überlebt nicht so lange ... also sparen wir doch einfach ein paar Byte"
und eh man sich versah, war das nächste Jahrtausend da
(ja, ich weiß ... 10% der Menscheit kennt das letzte Jahrtausend nimma mehr)

[DeddyH]

Jepp, und was ist passiert? 0! Dabei hatte man sich doch soooo schöne Schreckensszenarien ausgedacht.

[himitsu]

aber auch nur, weil genügend (wichtige) Programme rechtteitig drauf vorbereitet waren,
also warum nicht gleich etwas vorplanen?

[Reinhardtinho]

Reicht es den nicht aus, den Prozentwert zu übergeben?

[taaktaak]

Ok, ist ja nicht verkehrt vorauszuplanen!
Aber Frage am Rande (die meine Unkenntnis von XML offenbart):
Ist XML für solch riesige Datenmengen überhaupt (und in der Zukunft) die richtige Wahl?

PS: "> 16 EB" sagt mir gar nix Was bedeutet EB?

[Reinhardtinho]

Vll. ExaByte?

[taaktaak]

huiiii,

Zitat:

eine Trillion (1018 oder ca. 260) Bytes

[himitsu]

@Reinhardtinho:
Beim lesen geb ich nur einen Prozentwert (%*1000) aus, aber am Ende die verarbeitete Menge
und beim Schreiben/Speichern hab ich noch keine gesamtgröße, drum geb ich da immer die verarbeitete Menge zurück.

@taaktaak:
Kilo Mega Giga Tera Peta Exa

Und wenn ich mir z.B. mal die OpenStreetMap-Dateien (.osm) angucke, dann sind das im Prinzip XML-Dateien mit dem einem Straßen-Verzeichnis ganzer Länder.
(das winzige Belgien ist z.B. nur 230 MB)

Und wenn man nicht grade einen DOM-Pparser (Document Object Model) nutzt, welcher alles in den RAM läd,
dann gibt es praktisch nur die Begrenzung des Speicherplatzes auf dem Datenträger.
Nja, egal wie groß die Datei ist, hat sie hier immerhin noch die möglichkeit direkt vom Menschen gelesen zu werden.

PS: INIs sind auch nicht grade für große Datenmengen gedacht (< 64 KB) und nun mache mal einen Export aller Pfade deiner Registry ... die .reg-Datei is dann auch nur eine mehrere MB große INI