Hello,
On Friday 19 August 2005 23:25, Chris Lee wrote:
> I have started work on a proposed addition to the cvs tree, but I would
> like some feedback on the subject before I get really gung-ho about it and
> end up having to radically change things before I submit anything.
>
> What I am working on is actually two different projects. The first is a
> MVC-designed gui administration tool which will probably take me quite a
> while to write. I've chosen MVC layout to make it easier to build/port the
> program for qt/gtk/wx/win32/whatever. Unfortunately I don't have a lot of
> experience writing gui apps, so I'm trying to learn as I go. At this point
> I have created only a local skeleton tree for this project, no code yet.
I'm a little unsure about what you mean by a GUI administration tool. Do you
mean a Bacula GUI console?
I don't know anything about MVC, but I am sure that none of our existing GUI
consoles really meets the users' needs. The current wx-console is a good
first step but needs a number of features as was reported in a recent article
on Bacula. One of the big advantages of wx-console is that it is portable --
it currently runs on Gnome/KDE systems, Win32, and if I am not mistaken on
Macs. The big disadvantage is that it is a reasonably complicated C++
program.
After a good amount of research, I am convinced that the future of programming
is shifting from C to C++ and from C++ to interpreted languages such as
Python. In addition, I am now convinced that Qt is superior to Gnome, if for
no other reason than it is C++ rather than C.
So, my approach to this problem is to start writing a PyQt program -- that is
a Python program that uses Qt for the GUI. Advantages: it is an interpreted
language so almost anyone can change it simply run it, no complicated
compile/link; it is Qt, which is with version 4.0 completely GPL; Qt is
vastly simpler than Gnome; Qt has designer, which is orders of magnitude
better than glade.
This is not meant to discourage you -- quite the contrary since this is an
important project. But you asked for our thoughts ...
>
> The second project is a library for bacula which reads a daemon's config
> file, parses it into structures, and then can manipulate the data in those
> structures before a) writing the config file back to disk, b) temporarily
> committing the config changes to the daemon without writing the file, or c)
> discarding the changes altogether. The end result of this -- I hope -- is
> to support console and gui commands to change resource records on-the-fly.
>
> I invisioned this capability allowing console/administration tools to
> connect to a daemon, retrieve a data stream representing the daemon's
> config, and then allow the adminstrator to change that data as described
> above.
>
> Regarding which file to parse and change, each daemon already knows where
> its default is and the file specified on the command line if -c was
> specified. The daemon should (if the console has sufficient access)
> return those values to the console and alow the administrator to select one
> of them, or select an alternate file which could be useful if you're
> completely reconfiguring your entire bacula suite. In addition, whichever
> file the daemon is currently using can represent a set of "live" options,
> allowing changes to be made, tested, discarded, or committed.
>
> Manipulation commands may be a hassle to implement in bconsole for all I
> know because I haven't looked at the bconsole source. However, I
> originally decided to work on this functionality for gui tools. You might
> think of it like a sort of remote interface to a bacula "control panel".
> Currently I have begun creating headers and some of the basic functions for
> this support, but it is nowhere near complete.
I think I understand this proposal, but I'm a little confused about the
details. You mention reading the original config file, but also mention
getting the config from the daemons. I'm unsure if you mean getting the name
of the config file from the daemons or getting the actual config data.
I believe that two thinks are needed here -- both of which should be GUI
programs, and IMO both of which should be written with Python Qt.
1. Is a program that reads the config file and allows the user to modify
presenting the user with all the various possibilities and ensuring that
correct and valid values are entered. The configuration for such a program
should be well defined and easily extensible so that the program can keep up
with changes made to Bacula. This is a non-trivial design task.
2. Is a program that allows a user to build a new Storage daemon or Client
from scratch or from sort of form, and ensures that it is properly integrated
with the Director configuration -- checking names and passwords to eliminate
all the kinds of problems we see today in adding a new client or sd to the
configuration.
>
> Now that I have forgotten the rest of the points I wanted to mention with
> this proposal, I'd like to hear what others think. I realize that this
> could turn very ugly, but if done well from the start it could provide a
> high level of administration ease. If this proposal is not plainly
> rejected I will continue my efforts.
>
> l
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
