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?
