Les Mikesell wrote at about 11:14:40 -0500 on Sunday, September 6, 2009:
 > Jeffrey J. Kosowsky wrote:
 > > Craig Barratt wrote at about 20:54:50 -0700 on Friday, September 4, 2009:
 > >  > Davide,
 > >  > 
 > >  > The basic problem with putting perl expressions in the config file
 > >  > (to make settings cumulative) is that it isn't compatible with the
 > >  > CGI config editor.  The config editor will get the intended computed
 > >  > values, but when it re-writes the config file it will just write the
 > >  > values, not the original expression.
 > >  > 
 > > 
 > > While the above is certainly true, my guess is that the CGI config
 > > editor and those interested in adding PERL to their config scripts
 > > address very different use cases. i.e., those who like the cgi
 > > interface are probably not going to be interested in playing around
 > > with perl code and vica-versa.
 > 
 > I don't think that's necessarily true - at least to the point that people 
 > who 
 > use the web interface wouldn't like a way to merge includes/excludes in a 
 > way 
 > that updating the master config file can affect existing hosts.  However, I 
 > think the systems needs some kind of 'group' layer between the master and 
 > host 
 > configs.

No one is saying that the dichotomy is perfect. If one wants
perfection, then no progress will ever be made in BackupPC development
given the constraints on resources. Remember the adage "perfection is
the enemy of the good enough."

The point is simply that users who rely 100% on the CGI tend to be
different from users who are happy to dig in to perl code and play
with the config.pl files directly.  I don't think it is at all
unreasonable to create additional tools and hooks for those
manipulating the config.pl script directly while warning users that
this power may not be fully accessible from the CGI. MANY other
programs only offer partial cgi configurable while providing more
comprehensive customizability to power users willing to dig into the
code. If that is not good enough, then you or other users are free to
contribute more powerful cgi code, but why should all users be held
back by the lowest common denominator limitations of the cgi
configurator?

 > > Even so, I imagine it would be possible to add a text window to the
 > > cgi interface that would allow users to append arbitrary code that is
 > > executed either at the beginning or end of the config file (or perhaps
 > > both).
 > > 
 > > Similarly, perhaps define and add a begin/end comment border that
 > > could be put around perl code in the config file to signal the cgi
 > > interface not to overwrite it and instead, preserve it in place.
 > 
 > Or - perhaps the web interface could permit specifying the name of another 
 > file 
 > to evaluate either after or instead of the main config file where values 
 > that 
 > apply to a set of machines could be maintained.  That still leaves merging 
 > array 
 > values as a special case that might or might not be wanted, though.
 > 

Well then you are potentially *doubling* the number of config files
since presumably you could potentially want to do this for each host.

It's still not clear to me that there are a large number of users who
are both dependent on using the cgi configurator and who want to write
customer PERL code. And even if there are a few, they wouldn't be any
worse off than the current situation.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/