I've taken a look at the multiplexing problems with the bat restore and have
the following comments:
For those of you who don't know exactly what we are talking about, when bat
(or any restore command for that matter) is in the in memory tree selection
routines, the Director is nested down in a subcommand interpreter that limits
the commands to those of the restore tree. If you have a GUI like bat, while
the user is selecting files from the Graphical tree, he/she can simply click
on some other item, say Media, and thus generate a command that is sent to
the Director that is normally handled by the main command interpreter, so
Bacula gets confused, and this can abort the restore command that is in
progress but not complete.
The problem with the current bat implementation is as I have mentioned, it
does not multiplex command, nor does it currently open multiple ports to the
same Director (which accomplishes a sort of multiplexing).
The structure of the classes is such that the Director has no class (if you
want it is sort of a NULL class), but each Director has a Console attached to
it and the console starts up the BSOCK (communications class). This allows
each window that is started for a given Director to use the communications
protocols that are defined in its console. The advantage is that there is a
single unified console (text display window) for each director, and the
console handles the details of the comm line, so each window needs only to
know what its console is.
That means we have:
Console -> Socket
1. Now either we multiplex the Socket, which would be a major change to the
Director source code (it may be the best long term solution), so is out of
the question now.
2. Or we create a second Console ->Socket pair for use with the Restore
command, which is by far the simplest kludge quickie solution, but has the
disadvantage of separating Console output to two consoles for the same
3. Or we block all other activity while the restore command is running (a bit
4. Or we re-arrange our classes (this would probably be something that can be
done in the short term -- a week or two -- probably *after* the first beta
release). The new arrangement might look something like the following:
Open/close connection, ...
So we would pass a Director class to each of the Stacked widgets rather than a
Console pointer, and the director communications would be done through the
new Director class (we just move the console routines there).
Now when the Restore window starts, it would get a Director pointer. It would
then create a new Director, based on the Resource pointer in the Director,
and would keep the existing Console, but it would cause a completely new
connection to be established, so there would be a new Socket pointer. Now if
all the I/O is done through the Director pointer, it will use the new socket
(multiplex), but any console/status output would automatically go to the one
and only console window associated with the director.
There may be other solutions, but these are the ideas I had. By the way, in
doing item 4, we can construct the new classes in keeping all the old
classes, then convert the panes one at a time as necessary.
My recommendation would be for the quickie fix to be item 2, which a better
fix being item 4, and some more thought put into item 3 as a possible long
term (6 month) solution.