
#include "bacula_template.inc" title="GUI Interface"

<h1>Implementing a Bacula GUI Interface</h1>

<h2>General</h2>
This document is intended mostly for developers who wish to
develop a new GUI interface to <b>Bacula</b>.
<h3>Minimal Code in Console Program</h3>
Until now, I have kept all the Catalog code in the Directory (with the
exception of dbcheck and bscan). This is because at some point I would
like to add user level security and access. If we have code spread
everywhere such as in a GUI
this will be more difficult. The other advantage is that
any code you add to the Director is automatically available to both
the tty console program and the GNOME program. The major disadvantage
is it increases the size of the code -- however, compared to Networker
the Bacula Director is really tiny.
<h3>GUI Interface is Difficult</h3>
Interfacing to a interactive program such as Bacula can
be very difficult because the interfacing program must
interpret all the prompts that may come. This can be
next to impossible. There are are a number of ways
that Bacula is designed to facilitate this:
<ul>
  <li>The Bacula network protocol is packet based, and
      thus piece of information sent can be ASCII or binary.
      </li>
  <li>The packet interface permits knowing where the end of
      a list is.</li>
  <li>The packet interface permits special &quot;signals&quot;
      to be passed rather than data.</li>
   <li>The Director has a number of commands that are
      non-interactive.  They all begin with a period,
      and provide things such as the list of all Jobs,
      list of all Clients, list of all Pools, list of
      all Storage, ... Thus the GUI interface can get
      to virtually all information that the Director has
      in a deterministic way.  See    
      &lt;bacula-source&gt;/src/dird/ua_dotcmds.c for
      more details on this.</li>
   <li>Most console commands all all the arguments to
       be specified on the command line: e.g.
       <b>run job=NightlyBackup level=Full</b></li>
</ul>
<p>
On of the first things to overcome is to be able to 
establish a conversation with the Director. Although you
can write all your own code, it is probably easier to use
the Bacula subroutines.
The following code is used by the Console program to
begin a conversation.
<pre>
\#include "bacula.h"
static BSOCK *UA_sock = NULL;
static JCR *jcr;
...
  read-your-config-getting-address-and-pasword;

  UA_sock = bnet_connect(NULL, 5, 15, &quot;Director daemon&quot;, dir->address,
                          NULL, dir->DIRport, 0);
   if (UA_sock == NULL) {
      terminate_console(0);
      return 1;
   }
   jcr.dir_bsock = UA_sock;
   if (!authenticate_director(&jcr, dir)) {
      fprintf(stderr, "ERR=%s", UA_sock->msg);
      terminate_console(0);
      return 1;
   }
   read_and_process_input(stdin, UA_sock);
   if (UA_sock) {
      bnet_sig(UA_sock, BNET_TERMINATE); /* send EOF */
      bnet_close(UA_sock);
   }
   exit 0;
</pre>
<p>
Then the read_and)process_input routine looks like the
following:
<pre>
   get-input-to-send-to-the-Director;
   bnet_fsend(UA_sock, &quot;%s&quot;, input);  
   stat = bnet_recv(UA_sock);
   process-output-from-the-Director;
</pre>
<p>
For a GUI program things will be a bit more complicated. Basically
in the very inner loop, you will need to check and see if any
output is available on the UA_sock.  For an example, please
take a look at the GNOME GUI interface code in:
&lt;bacula-source&gt/src/gnome-console/console.c



<page_prev name="Bacula Regression Testing" url="regression.html">
<page_next name="Bacula Daemon Protocol" url="daemonprotocol.html">
