Valid keywords for KIO.Job.addMetaData

I spent three hours last night, pulling my hair out, while trying to add a custom HTTP header to a StoredTransferJob generated by KIO.storedHttpPost.

In my naivety, I thought KIO.Job.addMetaData(key,value) would accept an HTTP header name as key, and the actual header value as value. I was twice wrong: "key" is a limited list of accepted keywords (documented in the obscure DESIGN.metadata file, buried in the KDE source tree and not linked by any tutorial), and "value" is the complete header (e.g. "Content-Type: application/x-www-form-urlencoded"). It's essential to get the key right, or the metadata will be silently dropped (argh); I had to fiddle with Wireshark to find out. By the way, the two essential keys you probably want to remember are "content-type" and the life-saving "CustomHTTPHeader""customHTTPHeader" (DAMN LOWERCASE C!!! it's wrong in the design document, btw.).

(That's the terrible thing about KDE APIs: lots of barely-documented quirkiness hidden under an appearance of ease-of-use. You start developing thinking that it's all going to be easy, and find out along the way that things are not really as simple as they seem. I guess I should be thankful that at least they have good web tools to browse and grep their source, and fairly complete doxygen docs... but it still hurts more than it should.)

If anything can go wrong...

Blogger forced people to move off FTP publishing... expect breakage.

The joys of Python and Qt

I'm currently working on a tutorial regarding MeeGo, the new Linux-based embedded platform born by the merging of (Nokia-sponsored) Maemo and (Intel-adopted) Moblin. MeeGo is probably the closest thing we'll ever get to a real "Linux for the masses": differently from Android, where Linux is just a kernel for Java to run on top, here we'll have the full GNU toolchain, X display, desktop technologies based on FreeDesktop standards, RPM packages, etc etc.

The main development toolkit for MeeGo, from now on, will officially be QT. This seems to fly in the face of reason, having two existing GTK-based codebases from both "parent" systems which have already been deployed on production devices, but it's actually a very smart choice, as I was reminded just today.

This morning, I was working on a laptop running Windows XP. I built a couple of forms with Qt Designer, then fired up my trusty IDE and wrote the main code, about 150 lines of Python that will download some files, manage a few controls and then display a web page.

After completing a full set of tests on the local machine, I copied it to my (Maemo) phone, and again it was working perfectly -- without any change, recompilation, deployment, anything. Then I went home and copied it back to a different laptop running Kubuntu Linux, and again it was running just fine. Had I had a Mac (or iPad?) laying around, I'm confident it would have run there as well without any change. Consider that the version of QT and PyQt was slightly different on all machines, just to give it a further twist.

Obviously this level of portability has a price. I had to write my code using constructs like QSettings and QNetworkAccessManager rather than messing directly with the Windows Registry or HTTP_PROXY variables. I have yet another (leaky) abstraction layer on top of the OS, which may or may not be to everyone's taste, and the program runs in a sandboxed runtime, which might be slower than natively-compiled code (although this is debatable, these days); but I didn't have to write three different codepaths for each and every interoperation with the OS. I didn't have to worry about having a $HOME or a %HOME%. If I have to worry about packaging is just because I have to write about the ins and outs of a particular platform; in other circumstances I could have simply relied on python tools to do the right thing.

Python and QT could finally deliver the dream of portability that Java promised, if only we give them a sporting chance.

CallBlocker for Maemo

Last week, Vinu Thomas came up with an ingenious script that will silently drop calls on your N900 if they come from a list of "blocked" callers. I never thought you could do that, but apparently there have been quite a few apps for this sort of things on more established platforms like Symbian and iPhone.

At first I suggested a few minor improvements to the script, then I thought I might as well repackage it in a proper application with a proper GUI. I asked permission to Vinu (something the author of "pycallblocker" didn't bother to do), and then I went ahead and put it on Garage.

So there you have it: CallBlocker 1.0 for Maemo 5. Note that it relies on the python2.5-qt4-gui package, currently available only in the extras-testing repository.

The current feature-set is quite limited: you basically enter a list of phone numbers, and callers (exactly) matching them will be sent a busy signal or redirected to voicemail.

It did get quite a warm reception on talk.maemo.org, so I'm motivated to keep development ongoing (at the expense of other, still-unreleased stuff I have almost ready). The current plan is to release a 1.1 version with support for suffix wildcards (e.g. entering +441234*, all numbers beginning with +441234 would be matched and dropped) and better daemon management. Then, time permitting, I'd like to have a 2.0 with features like blocking all withheld/private numbers, blocking SMS texts, blocking specific contacts from address book, blocking all numbers not in addressbook, blocking only during some hours, and possibly even a "whitelist" mode.

Once it reaches a certain maturity, I'll probably consider moving it to the Ovi Store, at which point PyQt licensing issues might arise, but we'll cross that bridge when we get to it.

KDE 4.4.0 on Kubuntu Karmic 9.10 -- a note of warning

I just upgraded my Kubuntu 9.10 "Karmic Koala" from KDE 4.3.4 to 4.4.0 using the backports repository. A note of warning: take a backup.

It took me something like 4 or 5 runs of apt-get dist-upgrade / apt-get -f install to get back a working setup. APT complained about a couple of things (python-qt3-doc conflicting with some newer package which includes the same examples, and Bilbo having been renamed Blogilo) but eventually pulled it through.

I was smart enough to backup the .kde home directory before launching a 4.4 session, and I'm glad I was. First run: Plasma crashed hard on a segfault, and didn't restart. Ok, this happened with some past upgrade already, let's just move away the old .kde home... got back a default desktop. Playing around with widgets, I hit another crash. And another. The culprit was always the Plasma Desktop, actual applications were running fine. Eventually, I moved back the old .kde home except the plasma* files under .kde/share/config/. This gave me back all my old KDE settings, except for Plasma. Win, I thought, and merrily set out to recreate my previous desktop arrangement.

Another crash.

So uhm. I'll try to track down what exactly Plasma doesn't like in my setup (which was, for the record, with two panels on left and right edge; Lancelot and a couple of QuickAccess widgets on the left, task manager and shutdown button on the right; two Plasma "views" and 4 virtual desktops), but if you are planning a similar upgrade, make sure you put aside some time for it, and get a good backup beforehand.

(I guess the question now would be "is it worth it?". Well, KDE does look more polished, applications are faster to launch and more responsive... it does look like we're finally at the point where one could upgrade from a 3.5.x release to 4.x and feel a bit awestruck.)

Mobile applications for Nokia phones with... javascript ?!?

A few days ago the lovely folks at NSManchester, an Apple user group, gave a chance to "the enemy" (i.e. Nokia) to present their technology stack and business strategies for attracting developers.

The two presenter were a bit underwhelming (understandable after they went through the usual, hellish experience with British railway services), and there was little talk of my beloved Maemo, but it's hard to dismiss the technology stack they have chosen to go forward. Key element seems to be the QT library they acquired last year, which I know and love through the original Python bindings. It's powerful and as cross-platform as it can be, with a lot of mindshare in the Linux and Windows communities; this said, it's still C++, and it's hard to get excited about C++ these days. Also, the runtime will gradually appear on new and recent phones but probably won't make it to older ones.

The second development platform they are pushing, however, was more of a surprise to me. Apparently, you can use JavaScript to write applications for recent smartphones (S60 5th ed. -- N97 and 5800 -- and S60 3rd ed. FP2 -- e.g. E72, N85, N96 etc). You can access GPS coordinates, contacts and calendar items, as well as having complete freedom to design the UI with standard HTML and CSS. You don't need to sign the resulting packages, the barrier to entry is lowered dramatically. This is potentially a game-changer, and I don't know why Nokia are not shouting it from the rooftops. Early adopters include Netflix, which uses a basic JavaScript interface to stream their Flash content (!) -- so yes, you can use flash as well. My head simply went "boom"; I must look into this stuff.

One other thing I noticed was the presenters' style, typically European: self-deprecation and brutal honesty about things that work and ones that don't. It was refreshing, after weeks of Yanks propaganda from Google and Apple pushing their new gadgets as "fantastic", "amazing", "revolutionary" etc etc etc...

Backupify

Thanks to the lovely gPodder on my Nokia N900, I've recently discovered the net@night podcast by Leo Laporte. Like many regular podcasts, it's mostly full of random chatting and showmanship. In this respect, "new media" tend to be exactly like "old media": forced by their own schedule to blabber for the sake of it. But I digress.

The best segment of Laporte's show is usually an interview with someone from a startup, which is a good way of finding out about new services. Yesterday, it made me sign up for Backupify, a "social media backup tool" which will scrape your GMail / Delicious / Facebook / Flickr / Twitter / Blogger / Wordpress etc etc and store all the resulting data in a safe place on Amazon's cloud. Not a bad idea: the first 20 years of the Age of the Internet should have taught us, if anything, that data is ephemeral and can disappear at the flick of a switch. What happened to Geocities is proof that today's giants won't necessarily be with us tomorrow. Conscious of this state of things, Backupify gives you the option to drop your data on your own Amazon server, so that it will still be available if they go belly-up; quite a honest approach for a startup. It used to be a pay-only service, then went free to accelerate growth and get some venture capital; they will move to a freemium model after January 31, so you better try it out now if you can.

Good "Web 2.0" services usually expose APIs that make backups relatively easy for a programmer, but who's got time to write dedicated scripts AND the foresight to run them regularly? Myself, I've probably written half a dozen GMail scrapers, but I hardly ever ran them more than once. I've exported this Blogger-powered site once, and it was a nightmare. Backupify makes it very easy to "set up and forget", and that's good. The data will only be as good as what the various sites will allow; for example you will never be able to "restore" a Twitter account, so Backupify will only give you a PDF of your (and your friends') twits, which is the best you can expect. For Google Spreadsheets you get XLS files, for Blogger you get a big XML containing all your posts, etc etc.

The only problem with the site is the password anti-pattern: in order to get at your data, they often have to ask for your login details, and will store them on their servers. They do use OAuth if the service supports it (like Facebook or Google), but otherwise you'll have to trust them with your credentials. This makes them a very good target for black-hat hackers, among other things. I do hope they know what they are doing.

How the Nokia N900 is improving my life

(Small things, but...)

Today I had to took my car to the garage, so had to tell my manager I'd likely be late (public transport is not terrible in our area, but it still takes me about twice the time to get to the office than it would with the car). I'm also down with a laryngitis and I can barely whisper.

I could have booted my home laptop to send an email or IM, but meanwhile the bus would have come and gone. So I hit the road anyway, and thought I would somehow email from the phone.

But then, the Nokia N900 is no Blackberry; it's a full-fledged linux desktop in your pockets. When I enabled the 3G data connection, the button nearby was the one to set your IM status(es) to Online; so I fired that up, looked up my manager in the wonderfully integrated address book, and she was online, so while I sit on the bus, we had a friendly chat about things to do, without having to share them with other commuters or strain my poor throat.

All the while, I was listening to the latest Python 411 podcast about the (apparently terrific and currently-slashdotted) Sikuli project, updating expenses on the little program I've developed (which I'll upload to the Ovi Store in a few weeks, I promise), and browsing Google Reader. The 30-mins commute was over in what seemed like seconds, and the experience was basically the same I could have had while sitting at my desk with a regular laptop.

This little thing is simply outstanding. Apple's new "iWhatever" better have a SIM slot, or they can kiss goodbye to their iPhone marketshare.

The personal-GPS market has just died

Nokia just announced that the turn-by-turn navigation addons to their (underwhelming) gps software, Ovi Maps, will now be offered free of charge, completely undercutting TomTom and friends. They can do this thanks to the recent acquisition of Navteq, the top map-making company in the world (which is still selling map data to competitors at a hefty price, by the way, including Google); and they have to do it, because Google is doing it as well on Android and iPhone.

If Nokia can really deliver (i.e. actually improve Ovi Maps, which is quite frankly not as good as commercial competitors yet), 2010 will be remembered as the year that GPS devices became obsolete, like it happened to PDAs about three years ago. TomTom shareholders better run for the hills.

Remote shutdown on Windows

This might sound useless or obvious to many, but i didn't know it and it made my life easier today...

If you ever need to shutdown a remote Windows machine, and you can't access it with Remote Desktop or similar tools, you can use Shutdown.exe from another Windows machine, like this: shutdown /m \\my-remote-host

Additional parameters can be seen with /? but the most useful ones are:

/r

reboot after shutdown

/f

force shutdown -- useful when the machine looks stuck, which is what happened to me today...

/d xx:yy

give a reason for reboot. See /? for the available codes.

I hope this means I can say goodbye to dangerous hard-reboots...

Nokia Ovi Store Policies on SaaS / subscriptions: fail

(Chances are that nobody will answer this question, like it happened to this developer on forum.nokia.com, but what the hell)

I have an interesting business idea. I'll develop a mobile application with some interesting functionality, and I'll give it away for free. The application will contain an option to upload some data to a remote server, which you will then access from any computer as a regular site. The website will have some advanced features to analyze the data etc etc. The site will operate as SaaS, with a free 30-day trial. Basically, the site will make the real money, in a way similar to what FeedDemon and NewsGator tried a few years ago in a different market.

Now, if I wanted to do that on Nokia platforms, I would try and put my mobile app on the Ovi Store as a free download, right? After all, it will be a useful program in its own right, with the online services being 100% optional. Nokia / Ovi get a free, useful app enriching its (crappy) customer experience, the developer gets a big distribution channel, it's a win-win!

Except that landlords don't like uppity sharecroppers. From the Ovi Terms & Conditions:

4.7. Free Content Restriction

You are prohibited from collecting future charges from end users for Content that those end users were initially allowed to obtain for free. This is not intended to prevent distribution of free trial versions of Your Content with a later upsell option to obtain the full version of the Content. Such free trials for Content are permitted. However, if You want to collect fees after the free trial expires, You must collect all fees for the full version of Your Content through the Program. In this Agreement, "free" means there are no charges or fees of any kind for use of the Content. All fees received by You for Content distributed via the Program must be processed by Nokia.

Now, I can see the motive behind such a "racket clause". Nokia doesn't want Ovi to end up a cesspool of trialware, or to be associated with "click once and pay forever" scams. But the rule is too broad, and it reads like any SaaS scenario is simply out of the question (especially when you consider that Ovi does not support "subscriptions" at the moment, only one-off payments). SaaS is probably the best revenue model in the software world at the moment, and Nokia is telling developers they can't use it.

I honestly do not know if Apple put similar restrictions in place on their store. They probably did (and then some), control-freak as they are, and this is why I wouldn't want to touch the iPhone ecosystem with a barge pole. But Nokia was supposed to be trying hard to regain developer mindshare...

So the question I'd like to ask, before I shell out for the Ovi "publisher" license, is: dear Nokia, my application does something useful on your mobiles. It will then, optionally, send some data to my server, and I will personally collect money to have people access that data on the web, aggregated in various ways. Can I put the app on Ovi?

More notes on N900

The N900 is lovely, but the more I use it, the more I get the feeling that releasing it as a mass-market phone might have been a bit premature.

Take the "grid" icons. Technically, you can sort them: each icon can be given a "priority" number, and the lower it is, the higher it will appear. Technically, you can create additional subfolders and even auto-sort icons depending on the application classification (office, media etc). Unfortunately, all of this must be done *by manually editing an XML file* (/etc/xdg/menus/hildon.menu) plus several other text files (the .desktop and .application files in /usr/share/applications/hildon). For a consumer-grade device, this is shocking. It's even worse: if you mess up said files, the system goes in a "reboot loop" from which is very hard to escape (hint: get the flasher tool and use it with only parameter --enable-rd-mode, then fix the file, then use flasher again with --disable-rd-mode; if that doesn't work, you'll have to do a full reflash).

Also, it does not work with the SIM cards from network Three in UK and Denmark; considering that Three is a favourite of data-heavy users, who should be the main target for this device, this was a big mistake.

Some applications are clearly half-baked (Maps), and the Ovi Store is still closed. You make a big launch taking over the entire ad-space on Gizmodo for a day, and your supposedly flagship applcation store is not working ?

Nokia are slowly addressing these issues by releasing over-the-air updates, which is good, but the overall feeling remains: as released (late), the N900 is for hackers and hobbyists. Which, considering the platform potential and role, is a crying shame.

N900 first impression

Cool. Feels sturdier than iPhone. Opening the battery compartment is shockingly hard, which is surprising if you think that Nokia always paid a lot of attention to battery slots etc. The hardware keyboard is undoubtedly better than virtual ones, and key size is about right for my clumsy fingers. Desktop navigation is da bomb, incredibly better and more customizable than anything seen before. Default browser is lovely if a bit idiosyncratic, mostly due to the erratic touchscreen. Ah, the touchscreen: worse than iPhone, sorry. The stylus is still quite handy. Apps: quite a bit of them, after enabling the extras repository, and decent quality. Will try the ovi store later. The feeling is that, finally, Nokia built a device for the internet: the network is taken for granted and integrated everywhere. The web experience is so good that custom clients (e.g. for twitter or facebook) are hardly needed. I'm writing this post from MaStory, but I could have used blogger.com and the experience would not have been much worse. And of course, this phone runs linux. Which means that you can hack it to death, and that the market is fully open. S60 developers can officially retire, Maemo is simply on another planet. Now let's hope Nokia won't blow this massive chance...