Has anyone of you looked at openWRT?
BeOS / Haiku doesn’t need a registry. The BFS has the ability to store attributes for any file if the programmer so desires. Programs can be launched by application signature, without specifying location in the file system! BeOS / Haiku has messaging built into it’s core for any communication between programs and the OS. This allows programs that have no prior knowledge to communicate with other programs with any scripting hooks the programmer makes known to the system. Any program preferences are kept in one location /boot/home/config/settings (as was posted earlier). If the programmer desires, these settings files are text based and are easily edited with a text editor. The BFS is journaled to keep data intact. Let Windows and Linux wrestle with their registry implementations.
Marco Nelissen created an app in 1999 called PrefServer (http://www.xs4all.nl/~marcone/be/files/PrefServer-x86.zip) that addressed storing preferences and settings. Source code is provided.
Scott
K Scott. Thanks for an informative reply.
[I came back and edited this post for accuracy]
The Mac OS X methodology for this is worth mentioning (and basically the same as what several people are suggesting here).
System-wide settings…
/Library/Preferences/com.mycompany.myapp1.plist (xml)
/Library/Preferences/com.mycompany.myapp2.plist (xml)
/Library/Preferences/com.anothercompany.anotherapp.plist (xml)
System-wide resources (some developers put certain settings in here too)…
/Library/Application Support/MyCompany/MyApp1/…
/Library/Application Support/MyCompany/MyApp2/…
/Library/Application Support/MyCompany/SharedBetweenAllOfMyApps/…
/Library/Application Support/AnotherCompany/AnotherApp/…
User-specific settings…
/Users/TheUser/Library/Preferences/com.mycompany.myapp1.plist (xml)
/Users/TheUser/Library/Preferences/com.mycompany.myapp2.plist (xml)
/Users/TheUser/Library/Preferences/com.anothercompany.anotherapp.plist (xml)
User-specific resources (some developers put certain settings in here too)…
/Users/TheUser/Library/Application Support/MyCompany/MyApp1/…
/Users/TheUser/Library/Application Support/MyCompany/MyApp2/…
/Users/TheUser/Library/Application Support/MyCompany/SharedBetweenAllOfMyApps/…
/Users/TheUser/Library/Application Support/AnotherCompany/AnotherApp/…
(Probably not worth mentioning/discussing the old/deprecated local NetInfo database that was used in a sort of registry-esque way.)
Everything, of course, has pros and cons… even the Windows Registry. But I think most people would agree that the Windows Registry is pretty heavy on the cons side.
As a user (and developer), I absolutely prefer the method employed by Mac OS X. On Windows and Linux there is no standard used by developers; Windows developers often use several registry keys and/or INI files with basically no organizational pattern, and Linux developers are no better with their conf files.
The Windows registry doesn’t bother me, it never has… though I certainly don’t believe that system information and settings should be stored in the same place as user info & settings. I’m certain that if Windows users opening regedit.exe were asked if they wanted to load the system (HKLM) or user [HKU, HKCU, etc] hives vs. showing all of them on the left, then half of the forum posts you saw from people warning, “ZOMG! STAY AWAY FROM THE REGISTRY!!!1!” at various web sites would never have been made, as the user would have been able to select the appropriate hive, and any adverse affects could be constrained to user hives only.
The only problem then is applications that don’t clean up after themselves when installing, but that is not the system’s fault. If an application isn’t removing registry keys for itself then you can be 99.999% positive that it’s also leaving behind files in you system and programs directory… again, not the system’s fault.
BTW. skyos (.org) is nicely using (ripping off?) BeOS’ idea of using filesystem, flat files and attributes to implement it’s e-mail handling: http://www.skyos.org/?q=node/642
"…new Mail application completely integrates with SkyOS. For instance, all mails are stored as separate files with various attributes attach to it. So you can easily and quickly find every mail using the SkyOS Viewer and its query system."
PLZ don’t dismiss and drop the GOOD stuff that was in BeOS.
Yep, SkyOS is using Haiku’s MIT licensed BFS implementation. Has done so for quite some time and has even contributed back some improvements a while back, IIRC. Everything’s how it’s supposed to be. 
Rest assured, no active developer in the project is considering that. OTOH, “They” could be plotting something sinister…
Yep, SkyOS is using Haiku’s MIT licensed BFS implementation. Has done so for quite some time and has even contributed back some improvements a while back, IIRC. Everything’s how it’s supposed to be. :)[/quote]
Exactly
For those who missed that, it happened before OpenBeOS was renamed to Haiku even:
I also remember that they did a Windows application that could read SkyOS/Haiku BFS partition 
Yes, that was actually done by one of their community members named Peter Speybrouck (a.k.a. Darkness) - he used a fair amount of Haiku OBFS code to put that together IIRC.
[quote=myyr]btw, imho a regular BeOS filesystem IS structured, hierarchical and searchable, so why re-invent the wheel? and BeoS had an AMAZING filesystem, imho. and with all the journaling (i think it was journaling?) and all the attributes, it was all tested and working - why not use that (approach)?
maybe: just 1 folder - config (?), and in that 0-byte files named after the owner-application and all these files have attached attributes which are the configuration information - keys and values. simple, imho. and ANY tracker window can become a ‘regedit’.
-config (folder)
|-hterm (file=application name)
| -window.width=1000 (attributes=keys and values)
| -window.height=700
|
|-foobarN
| -parameter=X
etc
those keys and values could be also INSIDE those files, but then there’s always the question of linefeeds, case, formatting etc and one would need to use a text editor.
[/quote]
I like the idea of using BFS as a settings storehouse; however, I wonder if there is an even more intuitive way to use it.
Why not place all program settings as attributes to the executable itself (i.e. no /config folder)? When a user runs the program from the executable or has not customized settings, the attributes of the executable are used for the settings. If the user runs the program from a link; however, the meta-data settings of the link would override the meta-data settings of the executable. When a user modifies settings to a program, the attributes of the file/link ran from would be modified.
(Does Haiku know ‘where’ a program is launched from or is this hidden by the FS implementation of soft/hard links?)
[quote]
Why not place all program settings as attributes to the executable itself (i.e. no /config folder)? When a user runs the program from the executable or has not customized settings, the attributes of the executable are used for the settings. If the user runs the program from a link; however, the meta-data settings of the link would override the meta-data settings of the executable. When a user modifies settings to a program, the attributes of the file/link ran from would be modified. [/quote]
This is hitting a raw nerve exposed by Vista recently… One of the things I enjoy about Haiku is that there is no hidden voodoo magic going on behind the scenes. There is one settings file. If a settings file isn’t configured right, someone can tell you exactly where to change it.
Why not place all program settings as attributes to the executable itself (i.e. no /config folder)? When a user runs the program from the executable or has not customized settings, the attributes of the executable are used for the settings.
There are several scopes for app settings, and two primary ones: one is global for all users, the other is on behalf of the current user who is invoking the app (or rather who the app is running on behalf of).
You cannot manage user-level settings with executable file metadata, even if it was broken up by user such as with XML nodes. What if you have 20 users and 2000 settings? The metadata would grow out of control, not to mention the security and stability implications of all users having access to the same physical metadata to access their settings.
In all the major OSs (*nix, OS X, even, yes, Vista), the user’s app settings settings are stored in the /Users/{user}/ or /home/{user}/ directory.
On the other hand, BeOS / Haiku in the snapshot version / context we’re currently dealing with is not really a multi-user system. I would assume that the next version of Haiku would add more multi-user functionality, but proper planning for such things as this ahead of time would be necessary.
Jon
How about a YAML or JSON formatted text file for each application?
/boot/home/config/apps/[appname]/config.json
Very human-readable and easy to delete in case of corrupted settings.