Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[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.

[Codehunter]

So, Version 1.0.1 ist fertig. Ich hab mal eure Anregungen mit einfließen lassen. Steuerzeichen im String werden jetzt besser escaped und für die Typkonvertierungen wird jetzt TFormatSettings verwendet. Eine neue Idee von mir ist noch dazu gekommen: Die FormatSettings können jetzt als Metadaten mit in die INI gespeichert werden. So kann man sicher sein dass die Datei auf jedem System wieder richtig ausgelesen wird, egal welche Regionaleinstellungen man gemacht hat. Kleinere Bugfixes hab ich auch noch gemacht, das eine oder andere Memleak raus und einige Inkonsistenzen beim Thema Unicode.

Um die Metadaten zu verwenden kann man entweder den optionalen boolschen Parameter im Konstruktor angeben (TUniObjectIni.Create(Filename, UseMetadata) oder aber nachträglich die Eigenschaft HandleMetaData:= TRUE setzen. Letzteres wirkt sich aber logischerweise nicht auf den Dateiinhalt aus, der bereits durch den Konstruktor geladen wurde, sondern erst beim Speichern.

[Codehunter]

Update: Bugfix für das wilde Duplizieren von Sections in der INI.

[Codehunter]

Update: Property Section.Ident.Default hinzugefügt.

[himitsu]

Du solltest den Thread mal verschieben lassen. (einfach auf den Meldebutton bei einem der Posts hier klicken und 'nen Mod darum bitten)

z.B. ins Projekte-Forum
Dort darfst du deinen ersten Post unbegrenzt editieren und kannst somit immer die aktuelle Version/Datei gleich (übersichtlich) am Anfang positionieren.