Plugins research summary

I seem to get a fair few emails from people interested to hear me elaborate more on the subject of my research these last few years, so now that I have a few minutes, I thought I’d write things out to explain a bit more. Firstly, a warning, my writing style is simply that of a braindump – I don’t mull over my posts so they are not necessarily complete or polished. Blog posts are intended to spark discussion and thought, and I am more than willing to elaborate either publicly or privately – my contact details are clearly visible to the right.

So my research most recently has been in the field of the semantic web. Before that it was in plugin-based systems. In both cases, my home language was Java, simply because I really do like the language, and it is the one I have invested the most effort to learn its nuances. Despite this, the concepts developed in both research areas is really language-independent, so feel free to contact me even if you don’t use Java.

My plugin research was really about enabling at a very low level the ability for an application to be broken down into separate but interrelated building blocks. Ideally, such a system would end up with a tree structure, as this enables the ‘leaf nodes’ to be relatively independent from each other, whilst still being able to draw from a common kernel. This research was based around a complete rearchitecting of Centruflow, which resulted in a base ‘kernel’ plugin which takes care of the core functionality such as server communications, caching, logging, security, xml parsing, etc, etc, etc. From this plugin a separate plugin is launched that provides all the basic user interface components. From this basic user interface library, all the functional plugins can embed their user interface components.

In Centruflow, the entire application consists of plugins. Each plugin offers zero or more extension points, and zero or more extensions, which plug in to the extension points. In general, all plugins offer extensions for either the kernel or the base GUI layer, but it is not uncommon for a plugin to offer its own extension points. With this design, it is possible to have any number of layers in our plugin hierarchy, meaning Centruflow can easily entertain new functionality that was not necessarily ever considered in the original design specification.

That word – ‘functionality’ – is an important word. This plugin architecture really means we try to break each plugin down to offer a distinct aspect of functionality. This makes it very easy for different users to receive a very different user experience simply by varying the plugins they receive. As packagers of the Centruflow product, this is trivial – each plugin is a single zip file with a descriptive name. The exact functionality offered to a user is based on the files included in a distribution. For example, Centruflow has both a ‘standalone’ and an ‘enterprise’ version, each of which simply varies by one plugin; the rest of the Centruflow application remains the same. Of course, other kinds of functionality such as scheduling, reporting, amending, searching, tagging, etc, etc, etc can all be dropped in for either version.

This plugin focus is really useful from a developers point of view as well – it means that we can easily and quickly change focus should priorities change. Also, because of the plugin hierarchy I mentioned, we actually receive compile-time errors when a plugin is trying to use code that it should not depend on. This is possible because each plugin must declare which plugins it depends on. This means that our code remains cleaner as there simply isn’t that possibility to write spaghetti-code.

As mentioned, this is how the Centruflow client is written. On the other side of the coin is the Centruflow Server, which is the area in which much of my ‘semantic web’ research has gone. I was planning to write about my more recent research into semantic web technologies such as RDF, OWL, SPARQL and heterogeneous data merging (i.e. generating virtual data stores that are populated by multiple datasources, and can be queried using SPARQL and represented visually using Centruflow), but I think I’ll leave that for another post.

Please, if you have questions, feel free to email me or leave a comment here. If you are interested in me discussing a particular topic, feel free to ask me.

Calendaring and I

I have recently made a big move into using an online/digital calendar as opposed to the trusty ‘calendar on the wall’ approach of yore. I am now quite happy with what I have set up, so I thought I would quickly type out my approach in case anyone else was wanting to have a good calendar setup that can follow them anywhere.

I am a bit odd, I like software consolidation. I use Mozilla Thunderbird as my email client and RSS feed reader, and thusly have it open all the time. It proves to be a useful distraction when working. I do not however particularly like running lots of programs, so I did not even look any further than Mozilla Thunderbird for my calendar client.

I also like to share my calendar with those who are interested in what I am doing – but I still hide behind a private calendar so it’s an ‘ask and ye shall be possibly told’ kinda situation, not a free-for-all.

With my hosted accounts with Google Apps (I have two main ones), one of the features they offer is access to google calendar. I signed up for this, and proceeded to add in the calendars of people relevant to me, so that I can keep an eye on their plans. I then proceeded to input my plans, and set google to email me an outline each day.

Like I said, I am a bit odd, and I don’t much like web clients for my email/calendar/etc. I much prefer my software to be local and full speed, even if the data is stored in the cloud. This is why Centruflow is designed like this. Therefore, I am not going to keep a web browser open to my email or calendar – that’s just stupid in my opinion (which has no logical founding, by the way).

Fortunately, Thunderbird has the power of plugins (which I’ve long been associated with). Two plugins later (named Thunderbird Lightning and Provider) and Thunderbird has access to my google calendars, and I can also input other peoples calendars as I want (provided I have access of course).

Now I have my calendar details prominently displayed in my email app. Another cool feature is that Google mail will intercept my calendar invitation emails and put them straight into my calendar for me.

On another note, I was about to complain that I still do not have IMAP access in the hosted GMail account, but as is always the case, Google decided the bad news and derision that the masses of readers following this blog would create, just enabled it this morning. So, too my masses of readers, call off your assault, for the good people of Google have obliged – let this be a warning to them however! 😛

Obfuscating Java Code and Continuous Integration

Java is a funny language – the ease in which code can be decompiled is astonishing. Eclipse plugins exist to make it a simple double-click on a compiled class file.

I spent a fair proportion of time this weekend adding code obfuscation to one of my projects, and it was relatively easy, despite the complexity of the software. Code obfuscation is normally a matter of working out what files to obfuscate, specifying the library code these files depend on, and setting up an ANT task to run it.

In the case of my project, it is somewhat more complex due to its software architecture: it is entirely composed of plugins, which have weak interdependencies. To handle this I developed a few custom ANT tasks to discover each of the plugins, work out their relationships, and then obfuscate appropriately. This is a relatively nice solution, as with the rest of my ANT script, as it means that plugins can be developed with no interaction necessary to reconfigure the build script.

This is particularly nice when it comes to my continuous build server – I get hourly builds (where data has changed in our code repository), and nightly builds regardless that are now fully obfuscated. In addition, my nightly build runs a whole barrage of tests and report generation tools to always keep us informed.

It takes a fair while to set up such a system, but the value is immense – other people involved with this application can download a build that is no more than a day out of date. This allows for frequent testing, as well as the certainty that we can always build our software.

If anyone has suggestions for other things that a continuous integration server should run, then please let me know.

NZ-made Information Visualisation Software

In response to Daniel Lawson’s blog post regarding TouchGraph, I’d like to draw attention to Centruflow, which is a New Zealand based software framework that does precisely what TouchGraph does, but in my opinion better…

I’ll leave my justification for this for another day. I just wanted to get this blog out there to say to everyone: support New Zealand made! 🙂

A Formal Contract Language for Plugin-based Software Engineering

Just as a quick note for the future me (and to anyone interested), here is the paper I was involved in earlier this year, now that it is published. As is the title for this blog post, the title of the paper is “A Formal Contract Language for Plugin-based Software Engineering”. It is to do primarily to do with our research into plugin-based software such as Eclipse (which is completely plugin-based), and our thoughts on a way to strengthen the relationship between plugin and the plugin host (or extension and extension-point in proper Eclipse lingo).

Any questions feel free to ask.