• The Django server (yet to be named)
• The client daemon (backtracd)
• The backup library itself (backuplib)

As I mentioned in the previous post, the Django server will be based around Celery. This will offer me the ability to schedule a task for a certain date and time in the future, which is a huge part of the implementation taken care of.

One thing I am yet to figure out, however, is how the server will communicate with the client daemons. At the moment I'm thinking XML-RPC, but it seems to me that it will end up a sort of mish-mash of different technologies - as the Django server will be exposing a JSON API (probably via Piston). I have also considered running Django on the clients too, so everything can use JSON/Piston, but this seems at the moment like an unnecessary burden.

Another thing to consider is the data that is to be transmitted between the nodes. Should I use a bunch of fields in a JSON object to represent the success/failure of a job, and how much data was backed up, etc.? Another option is to pickle a Result object of some sort - representing a result as a Python instance to be interpreted by the server. These are the things I love to think about when designing a system, and I'll certainly have plenty to write about in the inevitable report.

Something I can work on in the meantime, however, is backuplib - the client library that will actually copy the data. At the moment, it's just a wrapper around rsync/tar. That probably won't change, but it will need to get a bit smarter in the way it handles failures (and restores, of course) if it's going to make for the basis a decent backup system.

Backtrac is a pretty old project, and one whose name I am likely to change once I'm working on it. It was started in my first semester of university last year, when I didn't have enough work to keep me busy. I didn't know enough about Django back then, though, so it was left unfinished and only half-working.

Now I think I know enough to pull this off, and it's a chance to do something I really enjoy - while getting marks for it in the process! If everything goes to plan I'll be supervised by Dr. Julie Greensmith, which I'm really looking forward to.

I'll be using an app called Celery to handle the background tasks, which will be simple "pings" to the client machines, telling them to start a backup. Celery uses AMQP, provided by a broker such as RabbitMQ (which is written in Erlang). It's usually used for processing intensive computational tasks, but can also be put to use for jobs that need executing on a periodic basis, like backups.

I can tell you're getting too excited, so I'll stop. Rest assured, though, I will be writing about the discoveries I make along the way to finishing this ambitious project.

To answer the questions for the compilers coursework, I wanted my sections to be numbered (1, 2, 3), my subsections to be numbered (a, b, c), and my subsubsections to be numbered (i, ii, iii). This numbering pattern matches that which is given in the question paper, whereby a number of nested enumerates were used. The default LaTeX section numbering however is (1, 1.1, 1.1.1). I finally found a way to alter this default behaviour by using the following code in the preamble:

 \renewcommand{\thesubsection}{(\alph{subsection})}
 
\renewcommand{\thesubsubsection}{\roman{subsection}.}

This code modifies the way that the counters for subsections and subsubsections are printed (section counters are correct when left at the default).

I hope this saves someone even the few minutes it took me to work this out, once I'd applied some logic! It's very useful to know that LaTeX has a counter for everything. This particular post was very helpful in working out which ones to alter, and how.

I've been working with Django more and more lately, and I've written my first "commercial" application using my new favourite framework - a booking system for taught causes at the City Council. I'm really enjoying writing web applications with Django, and I'm sure this blog will start to resemble a web-developer's in the near future.

Also, I'm really looking forward to this year at university. As I understand it, there's a lot more work to be done, but the software engineering group project should be fun - as long as my "randomly chosen" team are happy with us using Python!