HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] Dummy config files

George H wrote:
This is more of a request for future versions of HylaFAX+ aimed at Lee.
Is it possible that on install hylafax+ can create empty FaxNotify,
FaxDispatch, FaxAccounting,...etc files with a simple example inside
(preferbly from stuff that was posted on the mailing list) and it's
all commented out so it won't take into affect.

Understand that these are more than mere configuration files. In most cases defaults are already provided for bona-fide configuration files. Files like FaxDispatch, for example, are more correctly a "hook" or a "sourced script" that provides a means to customize (or "configure", if you will) not only the parent script's behavior, but also to do *anything* that the administrator needs at that point that is compatible with the parent script.

So, "simple examples" will very quickly include more elaborate scripting documentation to show how to do this or that or one thing or another. I'm not entirely opposed to that idea... but I've been hesitant to do it in the past, believing that those kinds of things more properly belong in documentation (i.e. the HOWTO) and that to include them in the installation does exactly what they're intended to to: encourage usage of those features and conformity in their usage. That has both pros and cons. It certainly may make it easier for the new user to utilize suggested or example approaches... but it also becomes their crutch. Whether or not including samples in the default installation would decrease the amount of user-support is debatable, I think. At some point the administrator *really does* need to read documentation and understand how things work. (I imagine that we'd see an uptick in the number of questions with respect to what $SENDER or $CALLIDn or $DEVICE actually refer to.)

I've preferred to leave documentation with documentation. This helps in that it keeps users looking to the documentation for answers... which is where users should be looking anyway. (If they turn first to the mailing list instead of documentation then they're only doing themselves a disservice... in that the responsiveness may not be terrific, in that the answer may not be as good as the documentation may put it, and that they become further dependent upon the mailing list for support.) It also helps translators know what to translate. It's an additional burden for them to need to translate documentation within config files.

I find that if we had those files we'd immediately open them and find
out exactly what we need instead of asking on the mailing list and
finding out we need to create a file. Rather we can just edit an
already existing file.

I understand the reasoning.

Let me state, however, that my current feelings are somewhat different from yours. I have found it frustrating when some RPMs install FaxDispatch by default, for example. Not only because wading through excessive comments to find the one line of scripting being used is sometimes like finding a needle in a haystack... but also because the users that I'm trying to help have often used (well, misused) the scripting in there... and it complicates my job of trying to help them.

Personally, I don't like (for example) when Asterisk's approach... "make samples" installs a ton of stuff that the average user does not want to use... and which may get left enabled unknowingly... but without it virtually nothing starts up by default. There really needs to be a "default installation" that targets at least a "minimally functional" installation without going so overboard that advanced users have to spend gobs of time disabling "default" features to get things buttoned down to where they want to be.

I know for my self I've read the MAN pages and I was still a bit
confused as to exactly which directory the files needed to be created
and what their names had to be.

I'm not in disagreement with you on this. Some of the "teaching" and "how-to" information really is inappropriate for man pages, which typically are dedicated to explaining program functions and command line parameters, etc. They don't typically strive to educate the user on how to do everything other than to provide a few program invocation examples. For some packages (like sox or wget) a man page is typically sufficient. For other packages (like HylaFAX, Asterisk, sed, awk, etc.) more is needed in the way of educating the user about how it all works together. This is one reason why I started the HOW-TO.

Certainly the HOW-TO may be inadequate still. It's an ongoing thing that I add to now and again. But I tend to feel that these kinds of "how to do something" things really belong more appropriately there than in configuration files.

So I dunno.. could this be done in the
next release ?

I'm not entirely opposed to the idea. I suppose that if it were only done in a 'make install_configsamples' or something like that kind of case then I'd be more accepting of it. However, the downside to that would be that I'd never use it, myself... and so the chances of those samples getting outdated (read: incorrect) or otherwise broken greatly increases. So someone else would really need to be committed to maintaining them... and to maintain them well they'd have to understand them well... and I wonder if understanding them well means that they, too, would also not use them. So... I'm undecided as of yet.



____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*

Project hosted by iFAX Solutions