[Bacula-devel-fr] Restore multiplexing problem

[Kern S. <ke...@si...>]

Hello Dirk,

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 
Director.

3. Or we block all other activity while the restore command is running (a bit 
ugly).

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:

   Director
        Open/close connection, ...
        Resource pointer
       Console  pointer
       Socket  pointer

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.

Best regards,

Kern