Not knowing how much off topic this would be, I just thought I paste a link here:
http://registry.sourceforge.net/
These people seem to be implementing a kinda Windows registry clone into Linux, but then secure, stable 'n' stuff...
Since the many registry implementation discussions here, I thought, why not throw this into the discussion too? It might be worth to take a look here and perhaps think about using some of their stuff.
Greetings, Robert van Herk
On Mon, Aug 30, 2004 at 03:27:49PM +0200, Robert van Herk wrote:
These people seem to be implementing a kinda Windows registry clone into Linux, but then secure, stable 'n' stuff...
I looked at this and, as it stands, the project is basically a bunch of hot air and a little bit of demo code that is far from "secure and stable". If it becomes widely used, it might create minor difficulties for Wine:
1. It has a tool called 'regedit', which conflicts with MS 'regedit.exe' and Wine 'regedit';
2. It does not preserve the key/value dichotomy in the Windows API (i.e., I could make a key "HKCU\Software\LMert\xx" and a value "xx" in "HKCU\Software\LMert" and set them to different values -- this is of doubtful utility but a natural consequence of the Windows API).
3. It doesn't have the REG_DWORD type, or any integer type for that matter, yet.
4. Right now, the syntax is actually pretty text-editor-unfriendly: it has no support for numeric values and it creates a lot of little five-line files.
However, the original author seems to want to move *all* config files in mainstream distributions over to his format, something that I don't see happening within the useful lifetime of Wine. Perhaps *they* should take a look at Wine code; as an LGPL project, Wine can't copy their (GPLv2) code directly anyway, and the Wine registry code actually has worked well for a long time.
Hmm,
How about a more general approach, then. I offered in the past to put wine's registry into a relational database, for performance reasons. That was turned down due to editability reasons.
However, how about we use a plugin mechanism. We will have the wine built in text-file registry handler, and we will also have a plugin mechanism by which we could write external registry handlers. This way, wine could have registry in a relational database, in a binary windows compatible file, or using these guys' project, and the end user will be the one to decide which is best for them.
David Lee Lambert wrote:
On Mon, Aug 30, 2004 at 03:27:49PM +0200, Robert van Herk wrote:
Lots of good reasons on why this project is not good enough to rely on.
Shachar