Default install paths

[spoilsportmotors]

Disclaimer:
I'm only an evaluation user, so my opinions may not count as much...

I had hopes that 3.2 would fix the default paths for data storage to use the Windows user interface guidelines; application data that applies to all users has a special home, and each user's data has it's own place. I'm disappointed that this hasn't been addressed, especially since it's very easy to do the right thing. There's a single function call - SHGetFolderPath - to get these paths from the system. This function is available to any Windows OS (including 95 & 98 if IE5 is installed).

I know that the default user can change the users directory to something more reasonable, but for home use, where I have several people involved, the only recourse is to point this to \Documents and Settings\All Users\Application Data\... which isn't really ideal. Each user should have their own set of data, in their own profile.

I know that I'm sounding awfully strident, and possibly even mean-spirited, but I really want an email client like Poco that actually follows the "Designed for Windows XP Application Specification", or even the 2000 specification. As a bonus, following these guidelines certainly helps with the claim of being secure.

Can anybody enlighten me on when - or if - these things would ever be fixed in either PocoMail or Barca?

--
Herb.

[Jim]

Disclaimer:
I'm only an evaluation user, so my opinions may not count as much...
...
Can anybody enlighten me on when - or if - these things would ever be fixed in either PocoMail or Barca?

--
Herb.

Actually your opinion counts. This seems like a useful feature and we will consider adding it in the future.

[spoilsportmotors]

Actually your opinion counts. This seems like a useful feature and we will consider adding it in the future.

Thanks. I appreciate you (and anyone else reading through this) not taking offense. Both PocoMail and Barca seem to be really nice products from what I've seen thus far.

And I sympathize with trying to meet the application guidelines, they're not all easy, particularly with respect to handling multiple users, and fast user switching. But you'd have one of the only (if not the only) email (or more, in the case of Barca) apps that did it right once you were done. FWIW, I'm a current user of TheBat! which also does not handle multiple users on a computer well at all. Given that they've just come out with v3.0 with no improvements in this area, I'm seriously shopping for a new email client.

Again, thanks for reading through some overly long-winded diatribes.

[Michael]

One of the questions that would have to be addressed here is what to do with scripts? Where should they live, in the personal directory (and therefore not shared between users), in the program directory (and therefore not updatable without rights)? A combination approach might be best, allowing scripts in both places with the personal directory taking precedence over the program one.

Similar concerns regarding address books and possibly templates. Also, should the bayesian corpus files be shared or not?

[Ian]

I have been thinking about corpus files as I recently set up a WindowsXP machine for my family and I think the strict answer is that each user should have their own corpus as each user will get different spam. Bayesian filters learn and therefore need training on each user's mixture of spam.


Ian

[spoilsportmotors]

One of the questions that would have to be addressed here is what to do with scripts? Where should they live, in the personal directory (and therefore not shared between users), in the program directory (and therefore not updatable without rights)? A combination approach might be best, allowing scripts in both places with the personal directory taking precedence over the program one.

Nothing should be stored in the program directory that a user should need to update. The program directory is for the application only; any configuration data for the application itself gets put in the "All Users\Application Data\..." directories. User specific data gets put in the "\Username\Application Data\..." directories.

Similar concerns regarding address books and possibly templates. Also, should the bayesian corpus files be shared or not?

Same answers as above. Although I think somebody (Ian) already addressed corpus files. They're probably a per-user item, although a separate feature might include the ability to share corpus files across users. From what I understand of Bayesian filtering, this would probably be of dubious value, though.

[COD]

I understand Microsoft's directives, but personally I like having all the program data in one general place, and Poco's very limited use of the registry.

[spoilsportmotors]

I understand Microsoft's directives, but personally I like having all the program data in one general place, and Poco's very limited use of the registry.

In fact, the (current) MS directives also state that less registry use is better, and they'd prefer none, if at all possible. Thus the recommendation of "\All Users\Application Data\[AppName]\...". Then all the application specific data is in one place, and furthermore, it can be backed up easily, and otherwise dealt with.

[Pete]

I can understand that MS would want application data files under the "Application Data" folders, but I would be surprised if MS is now recommending that application settings should also be stored in disk files instead of in the Registry. I'd be interested in reading the MS directive to which you're referring if you still have a link to it.

[Slaven]

It's definitely an interesting question. To clarify, one of the main reasons PocoMail stores all its files in the program directory is to make program maintenance and backup easier. Even though PocoMail defaults to installing into Program Files directory, you can install the complete application into My Documents tree and keep all your data safe there. There will be some extra overhead (since you're storing your EXE and HLP files there), but in PocoMail's case they are quite small. There is a way around that too with a /startin command line parameter. Furthermore, you can store complete PocoMail's tree on a network drive and have it work from anywhere. This is also the reason for PocoMail's reliance on configuration files, rather than registry (makes moving the application between computers very easy).

All that said, your point is very valid and as Jim said we have to accomodate all types of usage scenarios (not to mention Microsoft's guidelines)!

[spoilsportmotors]

I can understand that MS would want application data files under the "Application Data" folders, but I would be surprised if MS is now recommending that application settings should also be stored in disk files instead of in the Registry. I'd be interested in reading the MS directive to which you're referring if you still have a link to it.

The document that I am dealing with here at work - and believe me, we're going through or have dealt with these same issues - is entitled [i]“Designed for Microsoft Windows XPâ€Â

[Pete]

Thanks, Herb. Those are some interesting quotes from the spec -- thanks for not making me read the whole thing.

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).

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.

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.

[spoilsportmotors]

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...

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.

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.

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).