From: Joshua J. K. <jo...@ee...> - 2006-08-15 18:57:49
|
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 |