Re: [hylafax-users] Dummy config files

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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.

Thanks,

Lee.


____________________ 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*