[Bob Coe] > I'm not a Registry expert (Is anybody?), but I wonder if you > wouldn't lose the ability to register Spambayes for all users > of the computer, a capability that does exist currently.
What I was planning on doing was leaving the register for all users code exactly as it is. [Ryan Malayter] >> Of course, the spambayes program files and DLLs themselves >> would have to go into the %USERPROFILE%\Application Data directory, >> which is the only place a "standard user" can write on the machine. [Bob Coe] > If you must do this, at least put the files in the > "non-roaming" part of the profile, so the system won't waste > time and space copying them to the server. I have no plans to change the default installation location. If a user can't write to C:\Program Files (or wherever) then they can change that to somewhere they can write, or will just have to get someone to help them with the install. > More broadly, I think this whole line of discussion fails the > "If it ain't broke, don't fix it" test. Frankly, I think the > Spambayes installation process works just fine the way it is. I disagree. ISTM that managing your mail is a user process, and that installing a filter to help you do that isn't something that an administrator should be required to do (unless a specific organisation has rules about doing so, and then it's up to the individual to obey their own organisation's policies). > As a system manager, I should > have the ability to decide what software gets made available > to our users, and I see no good reason to make it easier for > an unsophisticated user to install and use software that we > haven't evaluated and don't support. As a user, I should have the ability to decide what software I use, assuming that it use of it doesn't go against any of the my organisation's policies, and that I do not expect any support from the organisation for it. I certainly should not need to go to my system manager and wait weeks for the extremely unlikely event of the system manager testing the software and deciding to support it and install it for me. I don't see why this is just for an unsophisticated user, rather than any user without admin rights. > Of course if the computer is yours, not your employer's, the > issue shouldn't arise: just give yourself administrator > privilege and have at it. Some people prefer to run without admin rights, though (some, probably misguided, sense of increased security), and if we don't actually need the additional rights to do the requested action, why should we require them? [Ryan Malayter] > I agree [...] I don't think we should hack SB so it is easier > for users to circumvent their organization's policies. My intent was/is to make it easier for people to install SpamBayes (and, from a selfish POV, to reduce the number of messages coming to [email protected]/the sf bug trackers), not to help anyone circumvent their organisation's policies. To be honest, I don't care what the users are doing with it - they're responsible for ensuring that they are behaving correctly, not me, and it's up to the organisation to check that their own people follow their own rules. > In fact, I think providing an MSI package for SB so administrators > can easily remotely deploy spambayes is a better idea. I have an > organization-specific package that I use now; generalizing said package > for any network may take some time, but I would be willing to do that > if people think such a package would be useful. There's an open feature request for this, I believe (although Inno, passed command line flags, can do pretty much all of what was requested). I'd be happy to check the code in if it was submitted, and to include creation of a MSI package in the build process (while I'm playing the release manager role) assuming that it wasn't arduous and didn't require any additional non-free software. =Tony.Meyer _______________________________________________ [email protected] http://mail.python.org/mailman/listinfo/spambayes Check the FAQ before asking: http://spambayes.sf.net/faq.html
