Re: [hylafax-users] Dummy config files

["George H" <george.dma@xxxxxxxxx>]

On Thu, Feb 21, 2008 at 7:57 PM, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:
> 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.

wow I never thought I'd get a big reply, but it means you've thought
about this a lot before. You state some very good reasons as well. I
figure you could compromise half-way. Put sample scripts in
/usr/share/doc/hylafax+/ dir and on install there would be a message
saying that sample scripts are there for anyone to read and a
disclaimer saying that they may not work right off the bat and use at
your own risk ...etc.

In the end it's your call and I think whatever you pick would be in
good judgment.


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