I'm still around though I felt sad to say that I was forced to put the
promised meta-data interface to hibernate for some must-be prioritized
projects.
I know you're disappointed but I am stilll looking forward to continue the
project as soon as I can.
I hope you'll continue to Cc me, albeit I am not that active of the moment.
Regards,
##jason##
"In a world without fences,
who need gates?"
From: cbarratt < at > users.sourceforge.net
To: "Josh McAllister" <josh < at > bluehornet.com>, jm_pernito < at > hotmail.com
CC: backuppc-users < at > lists.sourceforge.net
Subject: Re: ATTN: Craig Barratt - RE: [BackupPC-users] Web based
configuration tool for BackupPC... Date: Thu, 18 Dec 2003 02:56:26 -0800
Craig Barratt writes:
"Josh McAllister" writes:
It looks like there has been a couple of good starts, but if
development
of this is not coordinated with your own development it's somewhat of
a
waste as it has made obsolete the work done to this goal each time you
release a new version. (Not to say we aren't eternally grateful for
your
continuing development!
Leon said it well. Leon led an initial effort, but there was much to do
to make it flexible and usable. Since then the best prototype I've seen
is from Jason Pernito, as Leon noted:
I still have the source for the tool that I built and then discarded
when Jason Pernito built his tool. You can see screenshots here for
his
http://www.yoursource.netfirms.com/BackupPC/screenshots/ . But for
some
reason, I haven't seen any source code from him for the tool.
His interface was completely hardcoded, and I proposed a method to make
it based on some simply meta-data. I invited him to port his interface
to 2.0, but I never heard back from him. There are some design emails
that I exchanged with Leon and/or Jason that I could dig up if you
are interested.
Here is a design email I sent to Jason back in July.
(Jason, any updates on a v2.x version of your cgi editor for BackupPC?)
Craig
######################################################################
To: "jason pernito" <jm_pernito < at > hotmail.com>
cc: backuppc-devel < at > lists.sourceforge.net
From: cbarratt < at > users.sourceforge.net
Subject: [BackupPC-devel] Re: BackupPC_Admin changes & roadmap
Jason, I'd really like to include this in v2.1. But I would
like to base this on Config meta data, rather than hard code
each editable field. I haven't devised the format of the
config data, but we can come up with something pretty easily.
If we devise a format for the config meta data, would you
be willing to port your config editor to use this format?
Craig, I'm very much willing.
The Config meta data is also useful for future support of
an SQL backend.
Compound variables (eg: $Conf{BackupFilesOnly}) are a little
tricky; we should discuss which approach is best.
Yes indeed. Just give the go signal and I'll find time for it.
Thanks and looking forward to make sense contributions to BackupPC.
Great.
What I was thinking was we would build a simple meta data description
of which fields are editable and how they behave.
Here are some design issues:
- It should be easy to add new configuration variables to the
editing screens.
- Some values can be set on a per-PC basis, while other values
only take effect in the main config.pl file. For values that
can go in either place we need a way for the administrator to
set values either in the main config.pl file or on a per-PC
basis. It has to be clear what they are doing.
- (Advanced issue) When we upgrade the backend to use SQL we will
actually support one more class of config files (in addition to
per-PC and global). This gives three levels of config files:
- per PC: overrides any per-group and global settings.
- per group (eg: win-desktop): overrides global settings.
- global: master settings and defaults.
Currently the config editor should allow admins to edit the master
settings and admins and users can edit the per-PC settings. Later,
when we add groups, admins should also be able to edit group settings.
- We should only place values in the per-PC config.pl that are
different from the main config.pl. This allows an administrator
to set site-wide settings in the main config.pl file that aren't
overridden by the per-PC settings. It would be confusing if you
changed just one value in the per-PC config.pl file, only to have
all the master config.pl file settings replicated. There are two
choices:
- Currently you have a Default button that resets the value
to the master value. We can then only write per-PC config
values that are different from the master value.
- Or, instead of the default button, we could have a checkbox.
Selecting or deselecting the checkbox controls whether that
value is written to the per-PC config file. Whenever you
edit the value the checkbox is automatically set. Whenever
you deselect the value the text box is set to the global
value.
I prefer the latter approach since it is more explicit.
- Config values should be arranged by logical groups, eg:
Server configuration, per-PC settings etc, similar to how
you have done in your v1.5.0 work.
- It would be nice if the XferMode-specific settings only appeared
based on the XferMode. (eg: the Smb settings only appear when
XferMode is "smb" etc.) This might mean we should use some
javascript to submit and redisplay the page whenever the XferMode
is changed.
When an admin is editing the master config.pl values all settings
should appear: the XferMode-specific behavior should only be for
per-PC config editing.
- Some values are passwords, so they should be displayed with
password input boxes.
- We need to support i18n for the strings that are displayed (banners,
prompts etc). There will be a significant translation effort, but
as a start we can put the correct structure in place an at least get
English right.
- Some basic error checking would be nice, but let's keep it
simple. Making this flexible is difficult. Hardcoding some
error checking is ok.
- The per-PC config editing should be accessible from the PC CGI page.
- Changes to config settings should be logged in the log file.
- Administrators should be able to edit everything that is editable.
Users should be able to edit some things (per-PC settings).
Moreover, we should have a config parameter that allows the
administrator to specify a reduced set of parameters that
a user can edit, eg:
$Conf{CGIUserConfigEdit} = qw(
FullKeepCnt
IncrKeepCnt
BackupFilesOnly
);
- We need (somehow) to support some of the more complex data
types. For example, WakeupSchedule is an array of numbers,
DHCPAddressRanges is an array of hashes, BackupFilesOnly
is a hash of arrays. This is the most difficult area,
and it might be ok if we do some hardcoding here.
We're not trying to develop a fully-featured and flexible
editing system. What we're looking for is something that
works well and is extensible as new config parameters are
added.
Here's an example of what a menu definition might look like.
In one big data structure we define the layout of the edit
page. We could add one more layer for multiple edit pages,
but a single edit page is probably ok for now:
my < at > MenuDef = (
{
# banner text; not editable
name => 'GeneralServerConfig',
type => 'banner',
},
{
name => 'WakeupSchedule',
type => 'numeric array', # not sure if this is best.
# this would mean a comma
# separated array in one text
# box
},
{
name => 'MaxBackups',
type => 'integer',
},
{
name => 'MaxPendingCmds',
type => 'integer',
},
#
# and lots more
#
#
# Per-PC config values
#
{
# banner text; not editable
name => 'GeneralPerPCConfig',
type => 'banner',
},
{
name => 'XferMethod',
type => 'radio',
values => [qw(smb tar rsync rsyncd)],
perPC => 1,
},
{
name => 'SmbShareName',
type => 'text',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is
'smb';
# but always appears for master
edit
},
{
name => 'SmbShareUserName',
type => 'text',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is
'smb'
# but always appears for master
edit
},
{
name => 'SmbSharePasswd',
type => 'password',
perPC => 1,
xferDepend => 'smb', # only appears if XferMethod is
'smb'
# but always appears for master
edit
},
{
name => 'BackupFilesOnly',
type => '???', # this is a compound type; don't know
# what to do here
perPC => 1,
},
{
name => 'BackupFilesExclude',
type => '???', # this is a compound type; don't know
# what to do here
perPC => 1,
},
#
# and lots more
#
);
So in one data structure we can describe the entire structure of
the edit screen.
The code would simple pass through the array and emit the correct
HTML. On Submit it would make the necessary updates.
All the strings to display would come from the language specific strings.
For example, the english text for the banner names would be set in
en.pm as:
$Lang{ConfigEditBanner_GeneralServer} = 'General Server
Configuration';
$Lang{ConfigEditBanner_GeneralPerPC} = 'General Client
Configuration';
The prompt text for each parameter would also come from $Lang, eg:
$Lang{ConfigEditParamPrompt_MaxBackups} = 'Max backups';
The help text would be implenented as you have done, or otherwise
point to the on-line documentation (although it refers to the perl
config.pl syntax, which would be confusing for users).
By the way, the configure.pl script contains code for re-writing
config.pl files.
How does this sound as a basic architecture? Anyone should submit
comments now before we lock things down.
I'll think a little more about the CGI host editing and new host features
and get back to you on that. Having a full "self-service" feature so
users could add their own hosts would be great.
Craig
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
