>>>>> "mark" == mark bergman <[EMAIL PROTECTED]> writes:
mark> => I've got a plan to sit down and sketch out more consistent and clear
mark> => set of commands for manipulating bacula from the command line. Anyone
mark> => else like the 'bcli' name?
mark> =>
mark> No! No! This will only exacerbate the problem (if one defines
mark> the problem as "multiple tools/methods, with varying
mark> documentation and different levels of support for each
mark> tool").
My goal is to *replace* bconsole with a better tool, which does all
that bconsole does but in a more consistent manner. And which offers
cleaner interface to the underlying bacula commands and processes.
If you look at the source code to bconsole, the parser is very very
simplistic and doesn't have any notion of command completion, or even
the ability to give help at each level.
This should be replaced. As should the various .<cmd> versions of
commands as well, which are there to be used by external commands.
Also, as a pet peeve, why do we need a 'python' command inside
bconsole? Does anyone use it?
And what are the differences between:
list
show
status
Why do we have N different commands (cancel, disable, enable, run,
show, wait?) for handling jobs? It's a pain to figure out/remember
which one to use. I think it should be broken down more like:
job <cancel|disable|enable|run|status|*> <jobid|jobname>
instead. It shrinks down the help screen, it makes it obvious that
all job related commands are grouped together, etc.
We can also have a standard set of [options] which can be used across
commands, so that if you need to specify a particular server, you just
do:
bcli -h foo job run 12344
Nice and simple and consistent.
mark> There is a huge investment in bconsole--it's a fundamental
mark> interface to bacula, with a great deal of documentation (of
mark> varying quality), and many scripts & procedures are built on
mark> bconsole. Introducing a competitor will not improve bconsole
mark> directly, will not replace bconsole, and will create
mark> yet-another-way of doing the same tasks.
I don't want a competitor, I want a *replacement*!
mark> I'd be hugely in favor of improving bconsole in the following ways:
mark> 1. consistency
mark> standardize the "API" within bconsole so that every subcommand
mark> can take arguments the same way.
I agree.
mark> 2. documentation
mark> improve both the off-line documentation and on-line help
I agree.
mark> 3. command-line interface
mark> Many people (myself included) rely on complex scripts to
mark> execute bconsole commands. It's cumbersome and "fragile" to
mark> write scripts that blindly respond to prompts and menu
mark> structures of an interactive program. The scripts are
mark> difficult to debug and maintain as the program they are calling
mark> changes over time.
I agree.
mark> For example, I've got a script that includes:
mark> /bin/echo -e "update slots\n\nquit\n" | bconsole -c
./bconsole.conf
mark> note the "\n\n" sequence. This is vital, as the second carriage
mark> return is a response to an prompt issued within bconsole.
I feel that the example you show here is perfect for showing what's
wrong with bconsole. It should be something much more easily
scriptable, something like this:
bcli -c bcli.conf jukebox inventory
And I will be willing to change the 'jukebox' to something else, and
even the 'inventory' back to update. But let's get a more consistent
grammar here please!
mark> Once the internal bconsole commands are standardized, I think
mark> it would be a tremendous help to allow them to be called
mark> directly from the command line, rather than introducing
mark> another program. For example, the previous "update slots"
mark> command would be written as:
mark> bacula -c ./bconsole.conf update slots
I agree. But why should you need a -c bconsole.conf? What does that
buy us? Shouldn't we set it up so that when you connect to a bacula
server, the client pulls down the config info it needs?
But again, this should be all standardized.
I'd also like to see how reporting can be improved as well using the
command line tools. More on this as I get a chance to sketch out my
ideas and present them to people.
And initially it WILL be in a totally new program, which will just
call the bconsole tool from inside itself, just to show what I think
we need to do. Ok?
John
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
