Pete wrote:Thanks, Herb. Those are some interesting quotes from the spec -- thanks for not making me read the whole thing.
You're welcome - count your blessings that you're not also tasked with implementation based on the thing...
Pete wrote:I understand that using the HKLM branch would not work if every user shared a single set of settings. However, I think that most applications only use the HKLM branch during installation time (e.g. to store the registration key, installation path, etc.). Then, each user has his own settings in HKCU that they can change at will. I don't understand why you see this as a problem unless you think that all users should share a single set of settings (I personally wouldn't like this -- I think that users would want to be able to change their own settings).
Right. Effectively, HKLM is for data written during installation. Writing to HKCU for each user is not a problem, and used to be the recommended way of dealing with per-user data. As others have pointed out, it's a whole lot easier - and more secure, oddly enough - to use the filesystem to manage this data. This allows the administrator of the application to set the global settings, and each user to manage their own settings. In some ways, there's no difference between the two metaphors (disk and registry), it just that the now preferred method is to use disk.
Pete wrote:The only problem with this is if you have one user who maintains the settings for everyone else. In this case, that user would have to manually propagate any changes to the other users by manually logging in to each of their Windows' accounts and merging a .reg file. (I'm not aware of an easier way, but there certainly could be.) This would be one area where it might be preferable to keep the settings in disk files.
This is the "application administrator" role, in essence. If this stuff is stored in "\All Users\Application Data\..." (or HKLM as an analogue) then the app admin can read/write this data, and the users can read it.
Pete wrote:In any case, no matter if PocoMail uses disk files or the Registry to keep the settings, I think that we can agree that PocoMail still has some work to do if it wants to make this painless for PocoMail users.
No arguement there. And in all fairness, this stuff is non-trivial to fully deal with. Pop up the "Options" dialog for PocoMail. Which of those are global options and which are per-user? Repeat with all the configuration types of dialogs, and you can see the level of effort involved. In some respectes, PocoMail (and Barca) have an advantage due to their reliance on simple INI files for configuration.
My initial complaint was not registry vs. file system (they both have their place), but the idea of PocoMail or Barca relying on writing
anything to the install directory, instead of asking the OS for appropriate paths (or even registry keys).