Hello again,
> -----Original Message-----
> From: Kern Sibbald [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 20 August, 2005 11:12
> To: [EMAIL PROTECTED]
> Cc: Chris Lee; bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-devel] Some ideas I am working on
>
> 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'm actually referring to a gui application that does more than just serve
as another console. I'd like to implement a console view for it, but my aim
is to make all of the console functionality completely point-and-click for
those of us that want to be really lazy about administration. ;-) I also
plan to implement the online configuration editing capability described
below within this application.
I'm thinking of creating a kind of "layout" feature in which you can add,
remove, or edit objects representing various bacula resources -- from
directors, SDs, and clients all the way through pools and catalogs -- then
create visual and relational links between those objects to represent the
relational connections between the actual resources. This also would be way
more useful with the remote config functionality I talked about before.
Note that I still haven't decided what all I'd like to put into this program
and new ideas keep for it keep coming to me which I am considering.
> 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.
>
MVC is just an OO design method in which you keep the different levels of
application functionality separate from one another in the design. The
backend functions that actually do things are one part, the code for drawing
elements makes up another part, and then your element layout for what the
user interacts with makes up the other part.
In this way I can write an application that does something, create a gui
layout the way I want it, then write the gtk code that accommodates that
layout. But if another developer wants to do it in Qt then they just write
the qt code that accommodates the layout. I've chosen to go this route
because I know that plenty of people use KDE, plenty use Gnome, and plenty
use other WMs that can go either gtk or qt, and of course there's the win32
API. So by using this design the graphical code is separate such that
changes to the application itself shouldn't break it for a specific widget
set and each gui version of the app doesn't have to have a bunch of code to
dictate layout. Think, "One application - Multiple GUIs." I'm told that
mozilla is designed this way, though I'm noticeably frightened by the
thought of looking at its source.
It is entirely possible that I misunderstand the concept of MVC, however,
what I describe here is a major design goal of mine for this application.
> 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.
>
As for C++, I just never got around to learning C++ so whatever I write is
usually in C. You mention python as well and my position on that is
basically the same as C++. I don't know python so I can't really do
anything with it. I'm not opposed to using other languages, save that I
don't know them, but my opinion is that I can do all of this in C anyway and
with the MVC design, porting to another gui is as simple as adding functions
to tell the app how to draw in a different gui API.
> 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.
>
If I understand correctly the way MVC coding works, designing the visual
layout of the application is not something you do with a tool like designer
or glade. At least I don't know of any tools which facilitate this anyway.
Personally I don't really mind the extra effort involved in hand-editing and
testing the layout if it provides a means for allowing the application to
work with multiple gui APIs. And as far as the python/C/C++ argument goes,
MVC is just a design method, so writing it in an interpreted language should
still work the same way given a well conceived program structure AFAIK; but,
consider my position regarding languages above.
> This is not meant to discourage you -- quite the contrary
> since this is an
> important project. But you asked for our thoughts ...
>
Of course. :) I don't mean to differ or argue just for the sake of being
stubborn. I just have my preferences based on my current knowledge and
experience.
> >
> > 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 envisioned this capability allowing
> console/administration tools to
> > connect to a daemon, retrieve a data stream representing
> the daemon's
> > config, and then allow the administrator 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 allow 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.
>
Ok, this might be one of those times when I'm not proficient at
communicating my ideas efficiently or effectively, but I'll try to explain
in more detail.
I think that each daemon should have the configlib functions linked directly
into it. These functions should give the following capability to each
daemon, hopefully without bloating the daemon at all.
When the daemon reads its config file as it already does, the values that
are parsed from it are also stored in a "live" options table, which can be
changed. The multiple levels of console accessibility already present in
the director offer the opportunity to use it as the gateway for
configuration changes.
A console or gui application with configuration editing capability can
connect to a director and get a list of configuration facilities (the "live"
table, the default hard-coded config file, the config specified with -c on
the command line, and "other" which would be a user-specified path and
filename). The application in this case may have an option to save config
changes to a completely different file either locally or remotely as long as
the tool has permissions to write the file for local saves, or the user
running the remote daemon has said permissions for remote files.
Now that the tool knows where it can find configuration data the
administrator can select which configuration set he wishes. This could have
a default value set within the tool's options to automatically select a
particular configuration set such as the "live" table. The application then
asks the daemon for that configuration set. If the program is asking for
configuration from file, that file is read and parsed into a temporary
options table. If it's asking for the "live" set, that set is copied to the
temporary table. That temporary table is then sent to the application which
stores the table locally to operate on it. After the table is sent to the
application the daemon drops the temporary table and its memory is released.
Close the connection to the daemon at this point.
Now the console or gui application is able to present the administrator with
the current config data and let him add, remove, or edit whatever settings
he wants to. Whenever a change is made, that change is set in a second
table of options within the application which is used to store the changes
without losing the original settings (in case you say, "oops" and forget
what the option was set to before). The second table also makes it possible
to transmit only the difference between the original and new config set
which I'll get into below. Note that what I am describing on the
application end could be left up to that application's designer, but the
data exchanged between that application and the daemons would be restricted.
Whenever the administrator is ready to submit changes to the daemon, the
application connects to the director again. The application submits the
administrator's configuration data (either whole or difference) to the
daemon, which then parses those changes itself to confirm that the options
contain proper data and then stores it in a temporary table. The daemon
then (re-)sorts the configuration set in a logical manner (which is open for
discussion) to organize an array of resources with like resources grouped in
sequence. Next the daemon performs a config check on the new configuration
set as a whole to verify its sanity. If it passes, the application is
informed that the set is accepted.
At this point the administrator (via the application) can tell the daemon to
write the data to one of the configuration facilities the daemon
transmitted, or discard the changes (i.e.. because the admin decided to
scrap this config set and make other changes). If discard is chosen then
the table is simply dropped and its memory released. If the admin tells the
daemon to write the changes, then the table is either: a) copied to the
"live" table and then parsed by the daemon as if it were a config file on
disk, or b) parsed into a pre-determined layout and written to file with a
header comment indicating that it was automatically generated, reasonable
text formatting, and even comments if a comment value exists for a
particular resource.
To edit the configuration for a storage or file daemon the same process
would take place except that the application still connects to the director,
and the director relays information to and from the other daemon. This way
we don't have to bloat the file and storage daemons with extra console code.
The director already has the ability to authenticate the application based
on its Console resource(s) for administrative functionality like this. If I
misunderstand here how consoles authenticate and communicate with FDs and
SDs then I apologize and would appreciate correction.
> >
> > 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
I'm sorry to write such *long* emails, but I'd like to ensure that I'm
communicating exactly what I mean without leaving important details open to
interpretation or assumption. Again, I've already started work on the
config library and once it is a bit more complete I can send it to you and
see what you think. If it is to be included in future versions, then
I/you/we can work on putting whatever hooks are necessary into the daemons
and console. Additional comments and feedback are more than welcome.
Thanks,
Chris
-------------------------------------------------------
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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
