[Bacula-devel] Proposal for *THE* GUI

[Joshua J. K. <jo...@ee...>]

So, we've been talking about Libraries, GUIs, etc.  Kern wants a comprehensive 
GUI for Bacula, and I agree that it would be very beneficial, and move Bacula 
into a realm where it can compete (for some definition of "compete") with the 
more "prettified" backup programs out there.

So, here are my proposals for libraries, languages, etc.

<suit type="asbestos">

1. Library: C or C++, preferably C++.
I believe this would create the greatest flexibility down the line for binding 
to other languages.

2. Language for the GUI: Python
Dynamic, easy to code, completely cross platform.  While we'd still have the 
Bacula library to compile and distribute, using a dynamic language would keep 
us from having to compile and distribute three or four different binaries.  
By the way, this is not any kind of "mother tongue" language bias: I've read 
one python book (O'Reilly Learning Python), but to this day have not written 
one line of Python code.  I'm thinking about making myself learn it, however, 
for a project here at work.

3. GUI: Qt See: http://www.riverbankcomputing.co.uk/pyqt/
a) Qt would make the program immediately cross-platform
b) Has a powerful, but easy to use/learn, designer
c) Can create .ui files which can be loaded at run time to extend the GUI.  If 
we are using a dynamic language such as Python, "plugins," or dialogs/modules 
that extend the GUI would be trivial...maybe too trivial.
d) Stable, free Qt bindings: PyQt
e) PyQt has a py-uic binary to generate PyQt code for .ui files.

4. Bindings: SIP See: http://www.riverbankcomputing.co.uk/sip/index.php
SIP is designed specifically to create Python bindings, so would be a natural 
choice in this case.  Binding for other languages would have to be gone about 
another way, obviously.

5. Protocol: Text, but easy to machine parse
The current responses from the director will probably be OK, but they may have 
to be formalized some so that the front end can interpret what was returned 
to it and effectively determine how to best display it. Things like file 
lists, backup lists (when making a restore, etc) will need to be formalized 
and put into a format that is easily parseable.  At the risk of really 
offending Kern [grin], maybe a command that would cause the director to 
return all responses as XML? :)  Or at least something "well formed."

<suit>

Let the flames, er, discussion, begin.

As an aside: is there ever going to be a feature in the director whereby it 
can write config files?  I suppose the easiest way to implement remove config 
editing would be pulling/pushing the files via an SFTP link, so the GUI could 
edit them in a GUI fashion.  Hmm...GUI plugins...yummy.

j

-- 
Joshua Kugler                           
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE
PO Box 80086 -- Fairbanks, AK 99708 -- Ph: 907-456-5581 Fax: 907-456-3111