Steaming Ahead

Firstly, I'm really pleased to see that I'm getting some interesting comments - shame I haven't moderated them for ages. I'll get back to the issues raised in a later post, but here I want to tell you how I'm now charging ahead.

I took a huge leap and started on another rebuild. I've canibalised code from every version, live and experimental, but the key changes are that I'm building it on an SQLite database and using ClearSilver templates to generate the HTML.

There are a lot of advantages to this approach. I'll talk more about them later as well, but just for starters:

• It runs on a completely live database. Add a place and it will, instantly, be available for route planning and will appear in the drop-down hints for place entry
• Anyone who knows SQL can understand the database and add to it - and I haven't got to document these two large chunks of it, someone else has already done it.
  
• There are utilities to help me - the command line SQLite interface and a great Firefox tool to browse and edit
• Using templates means that pages either generate or fail, they don't break down half way though.
• The discipline of the templates really helps in design.
• It's not all written in my own script, and so it's much more capable of being taken forward by someone else. It would be a real shame for the project to rot if I was unable to keep it going for some reason.
• The projects are maintained - SQLite is in very active development indeed and while ClearSilver is quieter, it's not dead.
• They both are major projects - ClearSilver is behind Google Groups and Orkut, SQLite3 is everywhere, including in Google Gears, the Mac desktop, and the iPhone.
  

So why didn't I do it like this in the first place. Well, ClearSilver was first released on April 2006, SQLite3 - the first version with the features I need - came out in June 2004. CanalPlanAC has been live since Autumn 2001. I had to do it myself. But it was clearly meant to happen. I decided to use SQLite one day, and the very next they released a version with rtree support which is just what I need for POI data.

So why haven't I gone the whole hog and used a standard programming language as well? Mainly speed - I'm able to cut-and-paste large chunks of code from working versions because I keep the same scripting language, just chainging the in- and out- interfaces. Rewriting all this, and changing all the C to work with the other languages (the core route planning has to take place in something like C - it really is the grunt work).

As I am rebuilding from scratch, I'm making a number of other big changes which will support future enhancements:

• Internationalisation. The way I'm using and structuring the templates will make it easy to produce versions in other languages. That's very important in conjunction with...
• Expanded Geography. The core coordinate system is now latitude and longitude rather than OS grid. So it can support waterways anywhere in the world. In conjunction with ...
• The waterway sizes are stored in the database, not the code, so new waterway guages can be added and used. In conjunction with ...
• Different default options for different people (larger boats for example) because ...
  
• Boat sizes can be metric and imperial

So - there we go. An international waterway planner is only a few dozen steps away.

I'll be releasing a test version in a week or two, and will point you at it from here. When I do that I'll be starting another blog elsewhere which will function as release notes (and be a very good place for suggesting enhancements) while continuing with the bigger, stuff here.