Implement RegFlushKey

[Robert van Herk]

> 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