The result is XRDL, which retains XML-RPCs simplicity, while alleviating its single greatest shortcoming.

XRDL is being developed as a project under Google Code.

XRDL is basically a simple XML language which allows for automatic generation of type safe (as well as untyped) XML-RPC clients.

The project so far consists of:

• an XML Schema definition of XRDL
• a tool for generating XRDL definitions for services written in php
• a tool for generating php clients provided an XRDL service definition
• a tool for generating C++/Qt clients provided an XRDL service definition

So, XRDL is very much useful right now, assuming that your choice of server and client languages is like mine.

What’s obviously missing is tools for handling additional platforms and languages. The XRDL language itself is really quite trivial, so writing tools is really not all that hard. Why don’t you give it try for your pet language?

A number of solutions exist though. The most notable candidates

1. Googles Omaha
2. Sevenupdate
3. Wix ClickThrough
4. .NET ClickOnce
5. Software update wizard by http://www.powerprogrammer.co.uk/
6. WinSparkle

Each features its own set of problems (with the possible exception of “Software update wizard”). Looking at each in turn:

Google Omaha
Google Omaha sports a list of dependencies long enough to make me seriously consider if I even want to take the time to look into the project in any sort of real detail. Additionally, the server software required to make the thing work is google proprietary (closed source) code, so I am not really comfortable deploying it. In my opinion, it really shouldn’t be necessary with custom server software for a problem as relatively simple as this. If all else fails, I may take a closer look at Google Omaha though.

Sevenupdate
Seven update is an open source platform for deploying and updating software on Windows systems. From what I can tell, it pretty much fits the bill with respect to what I am trying to achieve. What has me worried about Seven update is the complete lack of documentation. At least, I am unable to find any documentation on the seven update web site.
Additionally, I can’t really figure out if Seven update is a complete stand alone application which must be installed on client machines. I would much prefer the automatic update software be embedded in the application installer, and callable at application startup time (again, much like Sparkle). I am not even sure that deployment in a corporate environment is even possible using Seven update. And did I mention the complete lack of documentation?

Wix ClickThrough
While the Wix ClickThrough project sounds like a usable and powerful approach (especially considering that we are already using Wix for creating installer packages), the project appears to be mostly vaporware. As far as I can tell, it consists solely of a mission statement created in 2005.

.NET ClickOnce
ClickOnce is strictly .NET (or well, mostly so: http://www.codeproject.com/KB/install/MfcClickOnce.aspx). It appears to be fairly tightly coupled with the .NET framework and Microsoft Visual Studio. We currently use neither of those products, so ClickOnce doesn’t appear to be viable option for us.

Software update wizard
Looks like the most promising system. It’s a for-pay library, which appears to support automatically installing application updates in various forms. It’s UI leaves a bit to be desired, but it appears to be easy enough to customize to warrant looking into. I will probably give it a try over the next few days, and see if it can be made to do what I need.

WinSparkle
WinSparkle wants to port Sparkle to Windows, and while it looks like a promising project, it doesn’t appear ready for prime time just yet. As a bare minimum, it needs to support installing application updates, instead of just launching a browser pointed at the update page.

Off the top of my head, I can come up with exactly 4 features that the N900 has going for it:

• It supports multitasking in a very usable way. Indeed multitasking becomes second nature in no time, when using the N900 on a daily basis
• Deploying applications to the N900 is a breeze. Simply compile the application and scp it on to the phone.
• Development in Qt for the N900 is not only supported, it is encouraged. Mmm… Qt. I may be biased
• A massive screen resolution.

On the other hand, the list of deficiencies is just too long to ignore:

• The worst touch screen of any device seen in the past few years. I mean, how did this ever pass alpha testing, much less make it to the assembly line? Compared to the the iPhone, the touchscreen is neither precise, nor responsive. It doesn’t support multi touch, and with the N900’s extreme screen resolution, using finger navigation is next to impossible (a link in the Maemo browser takes up around 6 square millimeters). And the stylus: well it’s just so damn 1990’s.
• Portrait mode only supported in the Phone app. This is just plain horrible: In order to use the N900 as a phone, I need to unlock the screen (in landscape mode), start the phone app (or even worse, find the phone app in the list of running apps) still in landscape mode, once the phone app starts, I need to tilt the N900 by 90 degrees because, lo and behold, does in fact support running in portrait mode.
• Next to no apps supported via the Ovi app store or apt archives. And the few apps that are actually to be found, are generally of mediocre quality. I am not going to go into details though, as it makes me depressed.
• Kinetic scrolling of virtual desktops is sluggish and clunky. Specifically I expect kinetic scrolling to continue scrolling at the speed that I choose. The N900 however clunkily falls back to default speed as soon as I lift my finger from the swiping motion. Not a bug as such, but it sure doesn’t look all that impressive.
• Syncing with my Mac involved downloading a 3rd party iSync profile from some guys web page. I realize that Apple computers isn’t the most widely used brand out there, but still…

The list goes on, but given that “I” paid close to 5000 DKK for the damn thing, I really don’t feel like continuing this rant for much longer.
Adding insult to injury, I actually gave my old iPhone to my wife, so going back isn’t even an option. Frick.

In the case of ExtJS I’ve been working with the 2.2 branch (3.0 was recently released), and it has enabled me (the uncrowned king of ugly user interfaces) to create pretty, responsive and reasonably productive graphical user interfaces. Not only that, it also did the job causing a minimum of frustration on my part. It seems that for 99 out of a 100 things I want to add to a user interface, the guys at ExtJS thought of it before me, and added out of the box support directly into the framework. ExtJS is not limited to user interface design though, as “ext core” has all sorts of sweet helper functionality for writing generic non-extjs-ui javascript code. Topping it all of, ExtJS guarantees compatibility with all modern browsers in use, so I get to ignore the whole browser incompatibility extravaganza. Whoohoo.

Qt is much like ExtJS in the sense that it does most stuff right. It massively reduces the need for manually allocating/releasing objects, while at the same time extending C++ with a class library rivaling that of Java. Qt additionally supports native looking gui applications across Linux, Mac and Windows. It even sports a WebKit wrapper class allowing use of a state of the art HTML/javascript engine. In the context of the project that I’ve been working on, that’s simply a killer feature, not currently supported by any other software platform that I am aware of.
Last but not least, Qt introduces an extremely powerful, versatile, thread safe event mechanism called “signals and slots”. Except for the fact that it is implemented by means of yet another C++ preprocessor, it’s exceptionally nicely done.

All in all, I take most (but not all) of the stuff that I’ve said about frameworks back. Bugger.

So far, the migration has been completely smooth, thanks to Wordpress’ export/import features. Say what you want about the quality of Wordpress, but its level of usability is just plain impressive.

So, without further ado, a summary of online backup solution privacy goodness (again, I would like to remind you that I am not a lawyer, simply a concerned luser):

Carbonite

The Carbonite privacy policy looks a lot friendlier than Mozys. Carbonite distinguishes between two types of disclosure. Disclosing (a) your personal information, presumably your name, address, phone number, etc, and disclosing (b) your backed up data.

With regard to (a), the privacy policy contains the following:

Carbonite is committed to protecting your privacy. Carbonite will not, under any circumstances, rent, sell, or give away your Personal Information nor does Carbonite trade or exchange mailing lists with any other organization. Carbonite maintains this information; but we may disclose your Personal Information to third parties if we believe that such action is necessary to (1) comply with the law; (2) protect and defend the rights or property of Carbonite; (3) enforce the Carbonite Terms of Use Agreement.

Although slightly rubbery, I guess that is what is to be expected, so we move on to (b), to which the following quote refers:

Carbonite will not share your encrypted files with any third party unless such action is necessary to comply with a government or court order legally compelling us to do so.

That’s more like it. As I’ve mentioned before, handing over data when ordered to do so by the courts are clearly a no-brainer.

So except for the fact that Carbonite, like Mozy, is situated in the US (which during the Bush administration has become an increasingly hostile environment with respect to legal rights), there really doesn’t appear to be much cause for concern.

In summary though, Carbonite appears to be a whole lot more privacy friendly than Mozy. Moving on to IBackup.

IBackup

The Ibackup privacy policy appears somewhat more fragmented than those of Mozy and Carbonite.

It appears that the following paragraph, taken from the IBackup terms of use, defines the cases in which Carbonite chooses to share stored data with third parties:

(…) In addition, Pro Softnet may be asked to provide user data and logs as a part of a legal issue in a third party case by a court order or a subpoena, discovery request or other lawful process that may override privacy rules.

As was the case with Carbonite, IBackup pledges not to share stored data with any third parties, unless ordered to do so by the courts.

Conclusions

Both Carbonite and IBackup provide reasonable terms of use with respect to sharing data with third parties. That is, according to their respective privacy policies, stored information is only divulged under court order.

This is in contrast with Mozy Inc. which allows itself to share stored information with any third party at any time that they deem fit.

As neither of the providers publicly disclose their encryption algorithm implementation, the privacy policy/terms of use of the providers are pretty much all that users can rely on for keeping their private data private.

He writes:

C’mon people, do you actually think a company would just hand over your data to anyone with a badge that walks in the door?

(…)

Of course Mozy’s TOS says that they will comply with a court order to hand over your data if subpoenaed. That’s the law.

That’s fine. Don’t make statements to the opposite at the top of your privacy policy then. If I was suspiciously inclined, I would suspect that the company bets that nobody bothers to ready beyond the first promising paragraph. Also, I find it interesting that this guy completely ignores this excerpt from the privacy policy:

Mozy, Inc. may disclose Personal Data, including the data you back up with the Service, with or without notice (…) (c) at our sole discretion, where we deem it necessary to protect the safety of any individual or the general public or to prevent violation of our User Agreement or the rights of Mozy, Inc. or any third party.

As far as I can tell, that allows Mozy, Inc to disclose your personal data under any circumstances, not just when subpoenaed to do so.

Finally, Ryan makes some rather clueless statements about cryptography:

• He states that “(blowfish is )impossible to decrypt”. No it is not. There are no known attacks on the the algorithm, except, obviously brute force. That is not the same as it being impossible to decrypt.
• To my knowledge, Mozy, Inc’s blowfish implementation is not publicly available, which makes it impossible to determine if trap doors have been placed in the algorithm implementation.
• Mozy, Inc. actively suggests (in fact it is the default configuration) that users allow Mozy to select the encryption key used. This obviously allows mozy to decrypt any sensitive information contained in user backups. Couple that with Mozy’s statement about disclosing backup data at their discretion, and you have an interesting definition of privacy.

All in all, I am hoping that Ryan is neither in charge of PR nor security at Mozy, Inc.

I must say, the Mozy client works beautifully, and the 2GB free storage plan makes it easy to test the service without spending anything except the time. It took me less than 2 minutes to download and configure the mozy client to do remote incremental backups of a few select directories on my mac book. No problems.

So there I was, pretty impressed, until I decided to ready the Mozy privacy policy. It starts with the following:

We will not sell or market the email addresses or other collected personal information of registered Users to third parties.

We will not view the files that you backup using the Service.

We may view your file system information (file extensions, sizes etc. but not your file contents) to provide technical support.

So far, so good. Further down, however, I encoutered this:

Mozy, Inc. may disclose Personal Data, including the data you back up with the Service, with or without notice (a) if required by a subpoena or other judicial or administrative order, (b) where required by law, or (c) at our sole discretion, where we deem it necessary to protect the safety of any individual or the general public or to prevent violation of our User Agreement or the rights of Mozy, Inc. or any third party.

Now, I am not a lawyer, but that seems to be in direct contradiction with the first set of statements. The way I understand is this: At our sole discretion we may violate the privacy of the data you choose to back up.

Hmm. I am not sure I like that.

Additionally, it turns out that Mozy is based in Utah in the US. Again, I am no lawyer, but from what I can tell, the US have all but abandoned the idea of due process in their precious war on terror. For all I know, any old US government agency could waltz into Mozy’s data center and make a copy of whatever data they damn well want to.

Whoops. I just uninstalled the Mozy client.

Recently I found myself wanting some kind of notification thingy, which would allow Irssi to discretely notify me when when something interesting happens on IRC. Irssi, being a console app, doesn’t really have any way of supporting this, except through the use of plugins. So, I had pretty much decided to dive back into perl and write up a simple script for irssi, utilizing the Growl for notifications by means of the Mac::Growl package.

As it turns out, someone else already did. And not only that, someone else took the time to explain in meaningful detail how to get the whole thing working. So, now I have growl notifications whenever someone sends me a private message or says my name in a channel that I have joined.

I like good software.

I am not even going to begin to enumerate the problems that I have encountered, but they have been mostly related to various WSDL formats, some of which are unsupported by .NET, and some of which are unsupported by various Java based web service frameworks.

So, admitting failure, I decided to look into SOAP alternatives, and I came across XML-RPC. Unlike SOAP/WSDL, XML-RPC is extremely simple: The specification is 8 pages including examples, and there are client and server implementations for pretty much any language you can think of. So, what’s the downside to XML-RPC compared to SOAP (taking into account that I was going to use SOAP over HTTP only anyway): Well, WSDL, basically. XML-RPC does not statically define its endpoints, instead it is up to the client to know what methods/parameters are supported by a given XML-RPC service. Also, SOAP supports a number of data types not supported by XML-RPC, but not really anything that causes problems.

Depending on the server implementation used, it is in fact possible to automatically generate clients (kindof). More on this in a little while.