oth...@freeshell.org writes:

I would suggest that I'm not alone in this. In a lot of companies boxes are built using standard distros (of whatever flavour) and extras like sqwebmail are then added. I think it is just as reasonable to take distro limitations into account when providing documentation as it is when writing makefiles. I don't expect Sam to have access to every version of every distro but I know that he does act on "doesn't compile on X, this fixes it" and would hope that he also acts on "ispell doesn't put its dictionaries there on X, it puts them here, please amend the documentation."

I think there is. These days, for small (few users) dedicated mail servers it's cheaper to pay a point-and-click monkey (aka MSCE) to install Exchange than it is to pay me to install qmail/courier-imap/maildrop/ sqwebmail even though, from long experience, I know what I'm doing. Anything that forces people to hunt around for documentation scattered all over the place increases the initial learning curve to the point where Exchange becomes the obvious solution on grounds of expense. As I see it there are three options for adding multiple dictionaries:

1) Automate it (preferred)

2) Document it well and provide that documentation with Sqwebmail.

3) Abandon all further development of Sqwebmail.

I'm serious. We're getting a lot of people who insist on switching their dedicated mail servers to Exchange to get the functionality that Exchange offers and which is not yet available in the alternatives (at least not without each user installing custom connectors in Outlook). We're losing ground here. Not because the alternative is superior or because its additional features are actually useful but because we can't match the tick list. People are willing to pay big money for Exchange just so that webmail looks exactly like Outlook because they can't cope with the unfamiliar.

If we cannot at least make it relatively painless for people to find a readme in sqwebmail about adding extra dictionaries we're going to lose ground even faster. "Let me see. I can pay an expensive programmer to spend a day learning about sqwebmail and figuring out how to add stuff like dictionaries for French, or I can pay a point-and-click-monkey to spend an hour installing Exchange and get all that and more. Decisions, decisions."

If you're really big, like Yahoo, you can afford to invest time in something like Sqwebmail and enhancing it for your own needs or even writing something from scratch. If you're really big and owned by Microsoft, like Hotmail, you can run Exchange and glibly ignore the per-seat licence fees because they don't apply. If you're small, you have to decide if you can afford to invest the time to figure out all the stuff you need to get Sqwebmail working, and whether enough people will buy something that *isn't Exchange* to make it profitable.

The easier it is to install Sqwebmail and get all the extra features like timezones and multiple dictionaries working, the more likely it is to be used. The harder it is then the more likely that eventually Sqwebmail usage will decline to the point where Sam can no longer afford to work on it, and it dies. The more we can help Sam to improve Sqwebmail, the more likely Sam will be able to continue working on it, and the more likely we will be able to persuade customers that it is an acceptable solution.

Or it should fail gracefully, in that it builds but some things may be missing. But basically stuff like a script to automate finding timezones or finding dictionaries should only be part of the build in a beta release or once it is known they work on all supported platforms.

Thanks. It's something I personally needed. The alternative to writing it was to spend a lot longer cutting and pasting in an editor to end up with the same result. A script also has the advantage that it adapts to the timezones on the machine it's run on, whereas a file created using an editor has to be checked on every new machine (old timezones won't disappear but new ones may appear).

I have a limited number of platforms I can test it on. Red Hat in various versions. CentOS 3 (yeah, I know it's basically RHEL but my boss refuses to shell out for RHEL so that's as close as I can get) soon, though I doubt it differs significantly from any of the RH versions I have access to. FreeBSD I can't test it on completely because I'm only an unprivileged user on a couple of FreeBSD boxes, but I can test an adapted version of it to the point where I know it's generating the right info even though (obviously) I can't output the file to the right place. So I have to rely on others telling me why it's failing on other platforms.

OK. If you can tell me where NetBSD puts its zoneinfo files, I can fix it for you. I'm making the assumption here that any platform that accepts the timezone designators that Sqwebmail uses, like Europe/London, is using a sensible variant of the Olssen package, so perhaps I may need more info from you if that is not the case. But for now if you can tell me the directory that contains iso3166.tab and zone.tab that's probably enough. Of course, if they're not called that, or the associated directories are not in the same place, then I'll need more info.