Grenzen von INI

**himitsu**

Json ist das neue Ini!

Wohl eher XML. JSON ist eher das neue SOAP.

Alles, was mit INI geht, geht auch mit JSON (und noch mehr)
und alles was mit JSON geht, geht auch mit XML (und mehr).

Jenachdem, was man mindestens benötigt, nimmt man Einwas davon, was Dieses unterstützt.

PS: Registry ist das neue INI.

Zitat von Lemmy:

Json ist das neue Ini!

Nichts gegen Json, ich bin schon sehr früh drauf aufmerksam geworden und wenn es einfach wäre, ich würde es heute nutzen. Aber ich hab mir dreimal das Delphi dabei zerschossen irgendein Json bei mir zu installieren, nun habe ich es aufgegeben. Laut dem was man so liest ist Json etwas ultraeinfaches. Es kann mehr als Ini und ist nicht so überladen wie Xml. Und wenn man sich anguckt was es so können muss, dann dürfte es nicht kompliziert programmiert sein. Ich frage mich deshalb wieso es nicht einfach eine 1 Unit Erweiterung ist. Einfach einbinden und gut ist es. Alles was ich bisher gefunden habe verlangte entweder eine höhere Delphiversion oder ein Rattenschwanz an anderen Erweiterungen die man vorher installiert haben muss. Somit bleibe ich bei Ini, oder wenn es komplexer werden muss, dann... mal sehen.

Zitat von Dejan Vu:

Ist das dein Ernst? Für 0.5 Sekunden willst du einen Splash einblenden?

Ja, die Welt ist schon komisch. Vor 100 Jahren hat man sich für die Dinge noch Zeit genommen. Wenn ich aber heute ein Programm starte, dann erwarte ich, dass es sofort da ist. Wenn es nicht sofort da ist, starte ich es sofort noch mal. Eine halbe Sekunde klingt nicht nach viel, es ist aber die Zeit wo man sich fragt wo das Programm bleibt.

**Sherlock**

Nenne mir bitte zwei ernsthafte Programme, die in weniger als 0,5 Sekunden geladen sind. Das ist ja schon die Zeit, die es braucht, bis die Exe aus dem Fileserver geladen wurde. Ich dachte ernsthaft, das wäre ein Fehler von Dir gewesen und du meintest Minute statt Sekunde...

Sherlock

**Jasocul**

Zitat von Popov:

Wenn es nicht sofort da ist, starte ich es sofort noch mal. Eine halbe Sekunde klingt nicht nach viel, es ist aber die Zeit wo man sich fragt wo das Programm bleibt.

Ein Wimpernschlag dauert ca. 0,1 Sekunde.
Ein Herzschlag ca. 1 Sekunde.
Die Zahl "21" dient als Hilfe, eine Sekunde zu "messen".

Ob bei diesen Zeiten eine halbe Sekunde wirklich ausreicht, um sich zu fragen, ob das Programm schon gestartet ist, bezweifle ich ganz stark. Ab 2 Sekunden würde ich dir vielleicht Recht geben. Es gibt übrigens auch einfache Mittel, einen Mehrfach-Start eines Programmes zu verhindern (Stichwort Mutex).

Ich würde eher das Start-Verhalten grundsätzlich ändern. Die Ini-Datei kann vermutlich auch nach dem Start geladen werden. Möglicherweise auch in einem Thread. Eine Sanduhr während des Ladevorgangs der Ini-Datei kann auch ausreichen.
Ein Splash-Screen der kaum eine halbe Sekunde sichtbar wäre, halte ich für nicht sonderlich sinnvoll. Da blitzt dann höchstens etwas kurz etwas auf.

@Jasocul

Dann lass es nicht 05 s, sonder 1 s sein. Es ist eine merkbare Verzögerung. Und Mutex kenne ich auch, es geht aber nicht dadrum.

Zitat:

Ich würde eher das Start-Verhalten grundsätzlich ändern. Die Ini-Datei kann vermutlich auch nach dem Start geladen werden.

Wie ich schon im Einganspost geschrieben habe, eine Verzögerung merkt man nur auf alten Systemen mit langsamen Festplatten. Das Problem existiert also nicht wirklich. Der Aufwand sollte also dem Nutzen entsprechen. Und hier geht es um die ganz wenigen Rechner auf denen es eine Verzögerung von einer halben Sekunde gibt.

Letztendlich sind die INIs das Problem. Ich muss mehre INIs öffnen, das kostet Zeit. Alles in einer INI und man würde es nicht merken.

**p80286**

Zurück zur Ausgangsfrage:
Irgendwo existiert da diese ominöse Grenze,(hier gab's mal was dazu) weil ein veraltetes API für die Zugriffe auf das .INI-File genutzt wird. Darum ist Deine Idee mit dem großen INI-File auch nicht soo gut weil dann die Zugriffe noch länger dauern.
(Immer vorrausgesetzt ich erinnere mich richtig!)

Gruß
K-H
doch noch gefunden:

http://www.delphipraxis.net/170130-i...on-1010-a.html

**Dalai**

Ich glaube mich zu erinnern, dass es zu Total Commander Diskussionen gab, warum denn bestimmte Einträge nicht gelesen wurden (war schon irgendein NT-basierendes OS, vermutlich Win2k oder XP). Als mögliche Ursache wurde dann eine Grenze von 64 KiB pro Abschnitt/Section angegeben und nach Verkleinerung einer Section unter diesen Wert lief alles wieder.

Ich weiß nicht, ob das auf aktuellen Windows-Versionen noch relevant ist, aber man kann das ja mal ausprobieren, aber zumindest im Hinterkopf behalten.

MfG Dalai

**BUG**

Zitat von Bernhard Geyer:

Wohl eher XML. JSON ist eher das neue SOAP.

REST ist das neue SOAP (naja, nicht

ganz so schlimm). JSON ist das für REST was XML für SOAP ist (obwohl REST nicht auf JSON als Datenaustauschformat beschränkt ist)

Ich finde

TOML für Konfigurationsdateien interessant, aber leider ist das noch nicht stabil spezifiziert und noch nicht verbreitet genug.

**himitsu**

INI, über die INI-WinAPI, wurde in einen 64-KB-Puffer (eine komplette Speicherseite im virtuellen Arbeitsspeicher) eingelesen und da drin verarbeitet (und das bei jedem einzelnen Lese/Schreibzugrif jedes einzelnen Wertes komplett von Vorne)
Lösung: TMemIniFile (das benutzt nicht diese API und ist auch noch schneller)

INI hat aber einen Vorteil, da dort jede Zeile einzeln analysiert wird, ist es der API egal, ob die Datei kaputt ist (also in der Datenstruktur), denn solange die SectionZeile und die eine WertZeile bis zum = OK sind, kann dieser Wert auch ausgelesen werden.

**Der schöne Günther**

Eigentlich bin ich jemand der immer gleich auf den Hype-Train aufspringt. Wenn etwas neu ist, ist es gleich cool und automatisch besser als das alte Gegenstück.

Nichts gegen JSON, sein Siegeszug ist verdient. Aber ich kann mich weiterhin nicht damit anfreunden, einfache Anwendungseinstellungen jetzt statt in einer flachen .ini-Datei in einer hierarchischen JSON-Datei abzulegen. Ich habe oft die Situation dass beim Kunden vor Ort noch etwas angepasst werden muss. Und jeder nicht allzu PC-versierte Techniker kann eine ini-Datei bearbeiten. XML oder JSON bringt solche Leute zur Verzweiflung. Deshalb sehe ich weiterhin immer davon ab.