[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Patch: Update Volume Command
On Friday 29 February 2008 00.33:23 Allan Black wrote:
> Eric Bollengier wrote:
> > Good idea, but it would be much greater if this option was available in
> > user interface (menu). Direct command line is always
> > optional/obscure/undocumented.
> > We can imagine something like
> > update -> Volume -> RecyclePool
> > 1. Default
> > 2. Scratch
> > 3. ...
> > 4. *None* <----
> > Maybe by tweaking select_pool_dbr().
Just second Eric's request. I consider the menu prompt part the principal way
of interacting with Bacula, and the command lines are a sort of shortcut if
you know exactly what you want. The two forms can be totally intermixed.
The bottom line is that when implementing a new command, we really need both.
I see you agree with this, but just wanted to make sure that others
understand this philosophy.
> Yes, I agree. I will look at doing that, if you like. The potential
> sticking point, though, is that functions like select_pool_dbr()
> and get_pool_dbr() are called from several places in the code, so
> introducing a *None* choice would have to be done very carefully,
> or it will become possible, for example, to label or move a tape
> into the pool *None* :-)
> I would be happy to take that on, but I think it would be necessary
> e.g. to introduce an extra argument to the function, say a boolean
> "none_is_valid" or something like that, to enable the addition of
> *None* to the menu, then modify all the calls to that function which
> occur elsewhere in the director.
> If that is OK, I am more than happy to go for it.
Yes that is OK -- it is how I would have resolved the problem.
> [ Anyone have any preferences for where the *None* choice goes?
> Beginning or end? :-) ]
My preference is the beginning.
> As an aside, I actually think that the only direct interface to the
> director should be single-line commands, with all arguments specified
> as keyword=value, and any interactive functionality implemented in
> the console program(s) - probably best done using a library of console
It seems to me that such a move would be very user unfriendly, and for those
scripting, it would require in some cases putting 20 options on the command
line when only one is sufficient.
> There are inconsistencies in the way the menus work - e.g. if you want
> to change a volume's recycle pool, you could issue the command "update"
> with no parameters, and the director will prompt you for "Update choice",
> (select 1 - Volume Status), then "Parameters to modify" (select 15 -
> RecyclePool). Then you will be presented with a list of pool names from
> the database, to be selected by number.
> If however, you issue the command as "update volume=<volumename>", the
> menus work differently. You will first be presented with a menu of
> "Parameters to modify" (select 15 - RecyclePool), then you will be
> prompted to type the new RecyclePool name in free text, instead of a
> menu of valid pools as above.
The menu or prompting, in most cases attempts to get information from the
command line arguments prior to throwing up a menu. So depending on what
command line arguments you specify you will get more or less menus. This is
very convenient, because if you forget the client name, you just don't
specify that argument and Bacula will ask you.
The menu system and command lines started with a *very* small number of
commands. Since then it has grown far bigger than I ever imagined, and
consequently, it needs to be refactored -- particularly the aspect that
currenly any unknown command line argument (one that is misspelled) is
ignored and it should complain. However, refactoring it doesn't add any new
functionality, which is important for Bacula right now, so this project is
not on the top of our list.
Thanks for your help,
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.