Moving on from CCTray

What’s Wrong with CCTray

Before I begin this post, I just want to say that I am a fan of CruiseControl.Net and have used it with great results. I still have CCTray installed on my machine and think it provides a good view onto what is happening to our build servers.

Now for the “however”. Having looked at the code, and having developed a few additions for it, I’ve discovered that the code for it has some limitations. Here are some of the limitations that I’m aware of:

• No extension model for adding new functionality – new extensions have to be baked into the application (e.g. X10, speech, etc.)
• The application is starting to become bloated – there is no way to remove unwanted features (e.g.  the UI code when writing a console app, X10 because there is no need for it, etc.)
• It polls per project, with a separate network call per project
• It also polls per server, but not at the same time – thus introducing a delay between updating the queues and the projects

Given the small size of the application, you could argue that the first two points aren’t really that applicable, but I think as the application grows they will become more of an issue. And as I discovered when I wrote my CCCmd tool (which is a command-line interface to CCTrayLib), there’s a huge amount of additional functionality that gets included no matter what. We could split CCTrayLib into UI and non-UI components, which would reduce the size of the libraries (plus reduce the required dependencies).

However, my main issue is a more fundamental issue with the way CCTray works, read on…

From Projects to Servers

From what I understand, CCTray started as a project monitor. Initially it only monitored one server – from which the user would choose the projects to monitor.

As time went on, the developers realised that people would want to monitor multiple servers. So they added the ability to connect to multiple servers. This had the side affect of introducing the bug where the incorrect server name was displayed for projects with the same name on different servers.

More time passed, and queues were added. Suddenly CCTray needed to monitor the entire server, so new code was added to poll the servers and update the queues. I don’t know whether they looked at the project polling code, but a second set of polling code was added which included all the same information.

So, over time CCTray has added a lot more functionality, become more complex and has (arguably) not optimised code like it could have.

An example of this is the project vs. server polling. Each project poll downloads the relevant project details – nice and small with only the relevant project details are included. But the server poll downloads everything for the server – including all the project details again! It would be nice to use just the one server poll, which then feeds the information to the project polls.

What Am I Saying

My main point is not that CCTray and its code are horrible, but that a good redesign and perhaps rebuild is necessary. I say rebuild, as the project polling is right at the heart of CCTray and it would be challenging to refactor it out!

As well as the performance improvements (i.e. removing project polling) I think there are a few other factors that need to be considered in the redesign:

• Extensibility – the ability to add new functionality to the application without forcing everyone to include it. This would include both new transports (e.g. WCF, messaging, etc.) and notifiers (e.g. X10, speechlib, etc.)
• Robustness – the application should continue to work, even if an extension doesn’t behave properly (I currently have an issue with CCTray were if I use my own custom icons it crashes after a day or so)
• Modularity – should be able to build different front-ends that don’t include all the code for the other front-ends (e.g. WinForms, console, WPF, etc.)
• An update mechanism – it would be great to have some sort of auto-update mechanism where CCTray would be updated to match the server automatically (although this would need to be optional as I know some environment would not want this). This could also be used for selecting and updating extensions
• Logging – it would be nice (but not required) to have logging in CCTray, similar to the server, so it would make diagnostics and problem solving easier
• International – finally it shouldn’t be limited to just English

I know this list may seem to be asking for a lot, but I’ve thought on this a bit for the past few weeks and in my next post I’ll start to write up what I think could work as a redesign.

Stay tuned…