Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[Codehunter]

@Popov:

Ich hab mir auch mal EasyIniAppExe.pas angeschaut. Du wirst lachen, ich habe lange Zeit etwas ganz ähnliches benutzt. Im Prinzip ist deine Lösung recht einfach und macht den Code im Hauptprogramm ähnlich schlank wie meine Lösung. Der große Unterschied dürfte meiner Ansicht nach darin liegen, daß bei deinem Code bei jedem Lese- und Schreibzugriff eine neue Instanz TIniFile erzeugt wird. Wenn die Konfiguration recht umfangreich ist dürfte das irgendwann zu Dateikuddelmuddel führen, Stichwort Schreibcache.

Ich wollte vorallem eine Konfiguration, die ausschließlich im Speicher vorgehalten wird und nur bei einem UpdateFile oder SaveToFile wieder in strukturierte Textdaten umgewandelt wird.

@Himitsu: Danke für den Hinweis mit den lokalen Spracheinstellungen. Das halte ich auch für wichtig. Ich habe schlichtweg nicht daran gedacht. TFormatSettings gibt man da einfach als zusätzlichen Parameter an, sind overloaded Funktionen.

Das mit den codierten Zeilenumbrüchen ist vollkommen richtig, war mir schon bewusst, aber noch nicht dazu gekommen.

Mir ging es bei der Unit bzw. Klasse vorallem um das Prinzip, eine völlig eigenständige Implementierung von TIniFile mit neuem Designkonzept. Schließlich ist die originale Implementierung vom Ansatz her seit Delphi 1 nicht großartig verändert worden.

Man stelle sich ein Programm vor, das ein paar Hundert oder Tausend Settings speichert und lädt. Das ist mit meinem Konzept, denke ich, effizienter und man kann den Zeitpunkt des Dateischreibens auf Platte steuern, was mit der Unit von Popov nicht geht.

Mir ist auch irgendwann mal aufgefallen, das selbst bei einer einzigen TIniFile-Instanz bei vielen Random-Read-Write-Zugriffen irgendwann der Speicherinhalt durcheinander kam wenn man zwischenzeitlich ein Flush gemacht hat. Das ist mir bei meiner Unit noch nicht passiert.

[himitsu]

Das mit der neuen Instanz von TIniFile macht eigentlich keine großen Probleme.
Vorallem da der Speichermanager in Delphi (und vorallem FastMM seit Delphi 2006) das kompensiert.
Aber der Hauptgrund ist, daß die INI-API von Windows etwas unpracktisch ist, da sie bei jedem einezelnem Zugriff (Lesen oder Schreiben) die Datei komplett neu einlies und parst und dann wieder freigibt, da kommt es auf die Objektverwaltung von delphi nicht wirklich drauf an.

[Popov]

@Codehunter

Meine Ini war/ist auch nie dazu gedacht gewesen bei Massenzugriffen tätig zu sein. Es spricht zwar nichts dagegen ein Objekt in einer Schleife paar hundert mal zu erstellen und wieder freizugeben, bei TIniFile wird das aber mit einem Zugriff auf eine Datei kombiniert. Sollte auch nicht das Problem sein, aber wozu dann die Datei paar hundert mal auch öffnen und schließen. Für so was war das ja auch nicht gedacht.

Trotzdem, es geht hier eher um das Konzept wie man sich das alles leichter machen kann.

PS:

Du bist nicht zufällig der Codehunter aus Spotlight.de?

[Codehunter]

Also mir ging es um meine Projekte, die konfigurationstechnisch recht umfangreich sind. Weniger die Usersettings als Daten, die temporär anfallen oder Persistenz über Programmsitzungen hinaus usw. Da kommen stellenweise sehr viele Random-Zugriffe zusammen. Selbst TRegistry scheint da zeitweise ins Straucheln zu kommen. Daher mein Ansatz, die INI komplett im RAM zu halten.

Das TUniObjectIni kann theoretisch (und sollte praktisch) als globale Instanz während der ganzen Runtime mitlaufen und nur z.B. alle 5 Minuten mal auf Platte schreiben. Was ich noch einbauen will ist Unterstützung für Namespaces innerhalb des Ini-Files und threaded Dateioperationen. Und natürlich die Vorschläge eurerseits.

Der Denkansatz ist in meinem Fall einfach komplett anders als bei der gewöhnlichen INI. Das Konzept wurde ja vor Urzeiten erfunden als PCs noch mit 640 kB RAM auskommen mussten und CPUs kaum ein Millionstel der heutigen Rechenleistung hatten. Insofern kann man heute mit dem RAM ein bisschen verschwenderischer sein und sich auch häufigere Multibyte-Stringvergleiche leisten. Ich wollte eben etwas komplett objektorientiertes. Der prozedurale Anteil ist ja eigentlich nur als Rückwärtskompatibilität zum alten TIniFile gedacht.

@Popov: Jo ich bin immernoch der selbe Codehunter wie in Spotlight. Bist du noch der selbe Popov?

[Popov]

Das mit dem Halten im RAM ist eine gute Idee und erhöht die Performance je nachdem ungemein, es gibt aber auch Schattenseiten. So habe ich Programme bei denen ich im laufe der Sitzung vieles einstelle usw. Beende ich das Programm regulär, ist alle gespeichert, stürzt das Programm oder ich kille es über den TM, ist alles weg.

PS: Ja, es gibt nur einen Popov. Schön sich wiedergesehen zu haben Schade um Spotlight.

[Codehunter]

Über das Absturzproblem habe ich auch viel nachgedacht. Zumal ich hin und wieder wilde Experimente mit multithreaded Programmen mache, die grad am Anfang recht absturzfreudig sind. Aber sagen wir mal so: Im Vergleich zu TIniFile ist das nicht so grundlegend anders. Auch da hat der Windows-Schreibcache kackfrech alles verworfen was das zwischenzeitlich abgestürzte Programm noch hinterlassen hat. Wollte man sich da absichern, ist mir bisher nur eine halbwegs gute Lösung eingefallen: Den Teil mit der INI in einen Systemdienst verlegen und die ganzen Speichereien per Inter-Prozess-Kommunikation transportieren. Geht die Anwendung den Bach runter, dann kann der Dienst noch alles speichern. Aber machen wir uns nichts vor, dieser Weg dürfte performancetechnisch ein Krückstock sein.

Tja Spotlight, das war noch eine schöne Zeit. Irgendwie war das auch ein Relikt aus längst vergangenen Zeiten. Denn mir ist heute keine Plattform mehr bekannt, wo so ein bunt gewürfelter Haufen so locker und höflich miteinander umgehen täte. Wäre Peter damals gesundheitsmäßig nicht auf dem Zahnfleisch gegangen, dann wäre das wohl noch bis heute so. Aber schaltet man so eine Plattform einmal ab, dann erholt sich das nicht mehr. Was Delphi angeht hat die DP hier mehr als nur einen Ersatz geschaffen. Ich glaub Luckie war doch auch Spotlightianer bevor er die DP aufgezogen hat, oder? Aber was mir persönlich am meisten fehlt ist die Haustier- und Heimwerker-Abteilung gleich beim Delphiforum um die Ecke Was mir auch noch gut in Erinnerung geblieben ist: Als Spotlight damals endgültig abgeschaltet wurde hatte ich 9.993 Posts auf dem Zähler. Peter hat damals glaub ich den 10.000er Club kleine Geschenkchen gemacht...

[Popov]

Nun ja, INI ist eigentlich sowieso schon veraltet, aber ich hab den Schritt zu XML auch noch nicht geschafft. Dazu ist INI einfach zu einfach.

Was Spotlight angeht, lag das Problem vor allem an Peter. Als er mit dem Forum anfing, hat man Forensoftware genutzt, zuletzt hat sich die Boardsoftware durchgesetzt. Und da stand er mit einer proprietären Software die anfing Geld für Pflege zu kosten. Er hätte den nächsten Schritt wagen und mit einem vBulletin Forum neu anfangen sollen. Das alte Forum Readonly. Die Leute wären schon geblieben. Auch bei einem anderen Punkt hat er nicht den Sprung in die Neuzeit geschafft: einfach Moderatoren bestimmen die nach dem Rechten gucken und das Forum wäre ein Selbstläufer. Dazu hat er den Leuten wohl nicht genug vertraut. Nicht alles selbst kontrollieren müssen, bzw. einen Angestellten dafür abstellen. Das hätte er auch aus einem Krankenbett managen können. Zuletzt hat er sich mehr Arbeit gemacht als nötig war. Geendet hat es mit eine Art Burnout.

[Codehunter]

Ich habe sogar einige Zeit XML zur Konfiguration genutzt. Für Client-Server-Kommunikation nutze ich bis heute SOAP, was ja eine Unterart von XML ist. Doch dann bin ich zu der Meinung gekommen (wird jetzt ein bisschen weltfremd klingen) dass sich XML langfristig gar nicht durchsetzen wird.

Warum? Zum einen ist die Parserei zu aufwendig. Klar gibt es MSXML aber das will einerseits nicht jeder nutzen, aus verschiedensten Gründen (Lizenzpolitik, nicht X-Plattform etc.). Eigene Parser schreiben ist irgendwie hirnrissig. Third-Party-Parser sind meist kostenpflichtig und teuer.

Zum zweiten produziert XML Unmengen Overhead. Es kommt ja nicht von Ungefähr dass die großen Softwareschmieden ihre XML-Metadaten nochmal in ZIP umverpacken. Ich nenne da nur OOXML und Corel CDR als Beispiele. Microsoft hat fast 10 Jahre gebraucht bis sie in ihrem eigenen Office den hauseigenen Standard OOXML vollständig unterstützt haben. Das spricht in meinen Augen Bände.

Drittens zeigt sich schon langsam ein Trend gegen XML. Da wäre z.B. das W3C, das sich zuletzt bei HTML5 gegen eine Weiterentwicklung von XHTML und für ein Superset von HTML4 entschieden hat. Dann hat SOAP mit REST einen Konkurrenten bekommen, der technisch näher an INI als an XML dran ist. Auch erschließt sich mir nicht, warum man für seine Konfigurationsdaten ein Austauschformat wie XML verwenden sollte. Außer der eigenen wird sich in den meisten Fällen keine andere Software mit den Daten befassen.

Daher denke ich, kann man ruhig bei INI bleiben für Konfig-Zwecke. XML sollte man in neuen Projekten unter Umständen schon gar nicht mehr einsetzen.

Tja und Spotlight... Ich fand Spotlight gerade wegen der Baumstruktur gut. Das war auch sowas wie eine Hausmarke. vBulletins und phpBBs findet man wie Sand am Meer, die meisten sind auch noch schludrig aufgesetzt und nie über das Standard-Theme hinaus gekommen. Möglicherweise war die Baumstruktur in mancherlei Punkten sogar übersichtlicher als die Brettstruktur.

Was ich nie verstand: Peter hatte auf der SL-Startseite ein wirklich ansprechendes Layout, doch kaum dass man in die Unterseiten ging kam der dicke Stilbruch und man fühlte sich optisch zu Netscape-Browser und HTML3 zurückversetzt.

Problematisch war wohl die proprietäre Perl-Software mit der hoffnungslos und ersatzlos veralteten Datenbank - Sybase wenn ich mich recht erinnere. Peter war wohl irgendwann der Programmierer abhanden gekommen der das Ding aus einer gekauften Lösung weiter entwickelt hatte und so musste er sich notgedrungen selbst damit befassen.

Ich hatte ihm sogar mal angeboten, die Software kostenlos in PHP und MySQL neu zu schreiben, aber das kam wohl zu spät, da war der Burnout schon in vollem Gange. Oder er hat nicht geglaubt dass man das in 4 Wochen machen kann mit heutigen Frameworks. Obwohl er gesehen hatte dass ich mit "Twilight SL" damals schon einen moderneren Reader für sein veraltetes Forum geschrieben hatte - in anderthalb Wochen.

Die Sache mit den Moderatoren hab ich genauso gesehen und ihm auch mehrfach vorgeschlagen. Aber er hat es nie als ernsthafte Möglichkeit in Erwägung gezogen. Ich denke, weil er die Nase viel zu tief in Gesetzen und Paragraphen stecken hatte und überall nur noch Abmahnungen und Anwälte gesehen hat. Vermutlich hatte er selbst keinen guten, internet-fähigen Hausanwalt, sodass ihm zwei oder drei Abmahnungen richtig viel Geld gekostet haben. Tatsächlich war es aber schon damals so dass er höchstens als Mitstörer haftbar gmacht werden konnte da die Inhalte ja nachweislich nicht von ihm selbst stammten.

Und so ist die vielleicht beste deutschsprachige Community ganz jämmerlich zum Teufel gegangen. Denn die Leute die da waren, das war ein unschätzbares Kapital und Peter hats nach meiner Ansicht nicht erkannt.