In the message dated: Wed, 28 Nov 2007 23:13:18 EST,
The pithy ruminations from "John Stoffel" on
<Re: [Bacula-users] All the problems with Bacula> were:
=>
[SNIP!]
=> Shon> here, I wouldn't have come as far as I have. For instance, the
=> Shon> full abilities of the commands aren't well documented. It
=> Shon> required searching the bacula-users posts to discover that I
=> Shon> could do "label slots=1-12 pool=scratch barcodes".
=>
=> Hear hear! I want to agree with this statement comletely. The
I agree!
=> bconsole command and it's builtin help is a total mis-mash and not
=> very user friendly at all.
I'd go beyond that...it's not just the builtin help. Bacula is a very complex
piece of software, with many different ways to accomplish the same tasks. I'd
say that bacula's main weakness is that these methods are often poorly
documented and somewhat inconsistent.
=>
=> I've got a plan to sit down and sketch out more consistent and clear
=> set of commands for manipulating bacula from the command line. Anyone
=> else like the 'bcli' name?
=>
No! No! This will only exacerbate the problem (if one defines the problem as
"multiple tools/methods, with varying documentation and different levels of
support for each tool"). There is a huge investment in bconsole--it's a
fundamental interface to bacula, with a great deal of documentation (of varying
quality), and many scripts & procedures are built on bconsole. Introducing a
competitor will not improve bconsole directly, will not replace bconsole, and
will create yet-another-way of doing the same tasks.
I'd be hugely in favor of improving bconsole in the following ways:
1. consistency
standardize the "API" within bconsole so that every subcommand
can take arguments the same way.
2. documentation
improve both the off-line documentation and on-line help
3. command-line interface
Many people (myself included) rely on complex scripts to
execute bconsole commands. It's cumbersome and "fragile" to
write scripts that blindly respond to prompts and menu
structures of an interactive program. The scripts are
difficult to debug and maintain as the program they are calling
changes over time.
For example, I've got a script that includes:
/bin/echo -e "update slots\n\nquit\n" | bconsole -c
./bconsole.conf
note the "\n\n" sequence. This is vital, as the second carriage
return is a response to an prompt issued within bconsole.
Once the internal bconsole commands are standardized, I think
it would be a tremendous help to allow them to be called
directly from the command line, rather than introducing
another program. For example, the previous "update slots"
command would be written as:
bacula -c ./bconsole.conf update slots
[SNIP!]
Thanks,
Mark
=>
=> John
=>
----
Mark Bergman [EMAIL PROTECTED]
System Administrator
Section of Biomedical Image Analysis 215-662-7310
Department of Radiology, University of Pennsylvania
http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
