> Therefore I did implement db-access in dokuwiki, by moving all file access > functions to 'io.php', and implementing simple db-write and db-read functions > that can optionally be called if enabled. Oops, Mario, I owe you a deep apology. I was thrown by your start with mentioning a no-file-write storage solution. While I'm not keen on that particular application, I do believe the solution you described has a strong bearing on the database-as-cache idea, and I don't want to dismiss you. I'm not familiar with much of the DokuWiki internals yet and don't know if there's a separation between cached-access and original access there. But the fact that you can do most of the job just by writing your own io.php is good news (and reflects well on our esteemed DokuWiki developers). Perhaps the database caching solution would be a hybrid of the current io.php and the one you've developed -- go to the DB first, and if not there, then to the file. Output would write to both file and DB. I don't right now have the time to pursue the database caching scheme. My main intent was to highlight the need to create clear boundaries in DokuWiki code for allowing this sort of solution in the future. It sounds like most of those boundaries may be there already. Again, I sincerely apolize for jumping the gun and cutting you short. I know how much it irks me when people do that to me. Actually, 'irks' is the polite word to describe my reaction. And thanks for doing the hard work getting a head start on database integration. Best wishes, ~joe -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist