HylaFAX The world's
most advanced open source fax server
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*