Main Area and Open Discussion > General Software Discussion
User settings storage debate
Ehtyar:
I must check myself. Josh and i have discussed this on IRC, and i am now aware of what it is he is pushing, it is most likely my misinterpretation of his words that got me all riled up. Josh believes that app config should be stored in the appdata/profile folder of the specific users, and i must say i cannot disagree with him. I would, however, be opposed to that being the only option available. If an application were to check the current users profile directory prior to check its own directory, i would consider that to be the ideal way of managing user configuration.
Ehtyar.
Josh:
It is, however, individual settings belong in the user's data folder, not in the program files folder. Unix has had this setup for years and its proven to be very secure and easy to setup.
f0dder:
Flexibility, please.
It's not a hard task coding up a configuration class that supports using both the registry (HKEY_CURRENT_USER, of course, since HKLM requires administrative privileges) as well as external config files (whether that be XML or LUA, please no .INI).
As for other configuration files (and where to store an XML or LUA config file), support both %APPDATA% and "alongside the program", to make everybody happy and support both Vista (as well as non-administrative NT4/2000/XP) and portable uses.
It's also not hard coding the program logic that decides whether to use %appdata% or alongside-the-program:
#1 - "userconfig.xml" present in app dir? -> use "portable mode".
#2 - "userconfig.xml" present in %appdata%? -> use "per-user settings" mode
#3 - config not found, ask which mode to operate in.
A HKCU registry check could be added either before, after or instead of step #2.
Ehtyar: one advantage with the registry is that entries are sorted, so lookups can be done with a binary search. Also, there's less text parsing to be done since it's a binary format. It's centralized, and very easy to backup HKEY_CURRENT_USER.
Ehtyar:
Again speed is mentioned. The difference (unless the file is huge, in which case perhaps using the registry would be a better option) will not be noticeable to the end user, and i can't imagine any case where backing up an ini (or xml/lua) in a directory could be harder than backing up a registry hive (would be quicker too if you insist on bringing speed into it).
Ehtyar.
[edit]
You'd also have to admit using the Reg* api is much more code than the *PrivateProfile* api.
[/edit]
Armando:
Yes, flexibility.
As a humble "end user" -- sorry if what I say might seem dumb or naive-- what I like and want is an easy to 1-find, 2-isolate, 3-backup and 4-recover, configuration/settings file. And I wish there was a unique convention for the way settings are stored. But, too often, it seems like a melting pot of registry settings, .INI, XML or LUA in the program folder OR the user's folder. Personally, I hate the registry for storing settings -- to me, the registry, if any, should be for the OS only. I prefer the *n*x way, seems more secure too, as Josh said.
I very well know that MS Windows' registry main function is to organize in one place (since it's a database, basically) all the settings which used to be scattered all around (in .ini files or whatever) ... But it just doesn't seem like the right way to keep track of software settings anymore. Like some here seem to suggest, the same results could be achieved if all software settings were stored in the user's folder, in clearly identified files and subfolders + in the program's installation folder ? It might use a bit more HD space (but it's less a problem nowadays), but it would be sooooo much easier to backup and restore individual programs' settings** and would insure that everything is portable (I guess I agree with ethyar and josh). No?
**I don't know any easy way to save software’s settings when stored in the registry. And I don't think I'm alone in that (especially since I'm basically an end user, not a programmer): "Restoring parts of the registry is hard because the user cannot easily extract data from backed up registry files. Offline reading and manipulation of the registry (for example from a parallel installed Windows or a boot CD) is not trivial" (wikipedia). BTW : Is there a quick way for a normal user to backup only ONE software with all its registry settings (and only it's own registry settings, not the whole registry), and only restore that software with its settings ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version