First, I would like to mention that having binary compatible registry implementation is not stricly necessary for load/save compatible to Windows. We can do import on load and export on save, for example. There is also the fact that, if I understand correctly, Windows 9x has different registry syntax from Windows NT, and other ugly stuff. If I understood the discussion so far, it boils down to these options: A. Ascii file - bad performance, easy editing. I'm unclear about Unicode support. B. Our own format - difficult editing, may have good performance if we invest LOTS of hard work. Lots of potential bugs and places to go wrong. C. SQL - good performance, jury is still out on ease of editing (in any case - not as easy as A, but I'm not sure how unicode plays in). Requires configuring yet another software component (but we may make that optional). D. Windows compatible - all the down sides of B plus bad performance.
Yes, I can defenitely see how D will be our favourite choice.
Just so I do not dump work on other people myself, I may not have time for implementing C start to finish, but I can defenitely help a lot. I'm already familiar with PgSQL, for one thing.
Did you discuss berkely db already? MySQL or another database app that requires a server to run wouldn't be a good option I guess, since you wouldn't want to have a seperate server running just to serve some registry keys. I know of applications (subversion for example) that just demand you to put the berkely db source into a db subdir in the src directory. After that, it finds it itself and stuff compiles like a charm.
Also, I didn't follow the discussion really, but did you think of something like this:
Initially make 1 big ascii file, as is used now. If the file gets bigger than some treshold, let's say 1 meg, use a hashfunction over the keys to split the file into a few new files that will serve as buckets. So, every time a file gets to big, just split it up.
In this solution, at least we will be able to reuse much of the current functionality. Only thing we need is a thingy to determin into which bucket (or file) a certain key was hashed...
Grtz, Robert