I have been still working on that program and it still isn't available but...
I have the website, nearly. I registered the domain as I needed to begin the process of setting up registration etc. The new website is at http://wpmaintenancerobot.com. Not much to see there yet I'm afraid but it's a start.
After much fiddling around with Pascal I found that there isn't a good module to do what I want to do with a website. The same issue with Tcl/Tk. Both these languages are pretty advanced in lots of ways but they just didn't have anything that matches Twill in Python let alone exceeds it.
After losing several months trying to make it work I finally stepped back, took a deep breath and picked up where I left off with Python. I'll just have to work out how to manage the compiling issue.
I have actually been having a go at that and discovered that I needed to re-write the GUI in Wx-Python because the module I was using, PythonCard, creates multiple files and doesn't compile well.
I have brought all the imports into a single file and written all the modules in the same file. This is not considered best practice as it can be difficult to maintain a program written this way. Unfortunately it is necessary to do it this way because the compiler tools only manage to import the dependencies for the main program and not the includes which means they won't be available and the program fails. Spagetti code here we come.
So here we are, 6 more months down the track and what do I have to show for it?
There are still a couple of bugs in the backup and restore modules. Nothing major I think but the backup just doesn't finish off nicely on one of my sites, I keep getting a 404 page not found error even though everything has completed and the output works on all the other blogs. Hmmmm. I'll find it and sort it out.
I realised that I needed to add significantly more security to the backup module. As with almost all the backup tools I was leaving the zipped up files on the host for later download. Anyone who got hold of my program, that would be anyone who wanted it, could identify how I was naming the files and then run a small program to check all known sites for the presence of this file, download it and have access to all the content, all the security tools in use, all the usernames and their access levels and all their password hashes. A brute-force attack on those hashes on their own computer would find collisions and therefore access to the site fairly quickly.
That can't happen now. The zip files are stored in the database as 64kb blobs in random order so even if an attacker gains access to the database they cannot put the files together again without the key, which isn't stored on the host. Of course if an attacker does gain access to the database then putting the files together is not something they would bother with, they already have all your data etc. No, this is not to protect you from direct attacks but to protect you from the attackers who have access to my program so they cannot learn how the files are stored and therefore create an automated way of downloading them from your database.
This may be overkill but I'm a bit of a belt and braces person by nature anyway. Can't hurt to be extra careful.
The other thing I have been surprised at is the lack of serious competition in this field even after four years of development. There are competitors but they seem to be mostly concentrating on putting all their eggs into plugin development and then using tokens to access other sites. This requires that all the sites you want to look after also have a plugin installed.
This is a major point of difference. My tool is a desktop based tool and all your data is safely stored in an encrypted database on your computer. It is as safe as your computer with a little additional protection thrown in. This does make you responsible for your own data but isn't that how it should be? Why should I trust a third parties website and host with the login details to my sites? I'm not even really happy with cloud based storage. It could change in the blink of an eye if the host goes belly up or decides to change the rules and locks down your data. Nup, look after it yourself. Use the cloud to transfer data but store it locally and remove it from the cloud when you no longer need it there.
Actually, don't remove it, overwrite it with non-sensitive data, save it and then delete it. Any recovery done on the files then will recover the last saves data not the sensitive stuff. Anyone who is interested in more information about WordPress security or what a secure password looks like can find it at http://guruburtlm.hubpages.com/hub/preventing-late-night-wordpress-cleaning.
Look for a progress update soon.