Ramblings of Narc

I got to travel a little bit a few weeks ago — my mother and I went to Borsec (actually, to nearby Corbu) to meet a friend of hers (who happens to have six Dachshunds, but that’s a story for another place). One thing we were warned about was the cellphone network there is spotty (and there’s no power where they live, but we didn’t stay with them, so that was okay).

They weren’t kidding. My lovely 3G modem could only connect at GPRS speeds, and even then the connection tended to drop out every once in a while — which was how I found out many of my favorite lovely little apps have a terrible, terrible time handling intermittent Internet connections.

Now, I’ll be among the first to recognize that broadband adoption has been increasing steadily at a booming pace in the past decade or more, but that doesn’t mean literally everybody has one, or that it’s impossible to go anywhere where one is not available. For that matter, it also doesn’t mean a broadband connection — any broadband connection — is perfect: they do drop sometimes, even if only for short periods, and this needs to be taken into account by any software that purports to handle transfers over the Internet.

On top of that, there is no real excuse for not handling all this stuff well — it’s the year 2009, and Internet connections have been getting widespread for at least 14 years. And they haven’t tended to be fast, reliable ones, either. There is plenty of software that has evolved to take these factors into account. On the Linux side, I only need to point to wget as a download agent that understands this fact and will happily allow a download to be resumed, retried, or restarted, as needed, more or less automatically, and wget is available in pretty much even the most basic Ubuntu system, and very likely in most other “mainstream” Linux distributions. Certainly, it represents an external dependency, but one that can be safely relied on by pretty much any Linux software author.

Except, for instance, the authors of gPodder don’t seem to have ever heard of it. Or, if they have, none of them have bothered making use of this mature, well-written solution to download handling, and instead implemented something written in-house, probably just as a quick ‘n’ dirty hack to quickly get some kind of downloading support in place, so they can at least get to testing the software and get a feel for it. Which would be fine… if it weren’t still in there.

Now, I want to be very clear that I am not specifically harping on gPodder for this. It’s far from the only piece of software that handles downloads poorly. In fact, I would like to turn a particular eye towards Firefox on this front, since I’ve never felt comfortable with its internal download support. Or that of any other browser, for that matter.

But what I would like to say is that the problem of downloads over an unreliable TCP/IP network is a solved one, and solutions exist for it — well-tested solutions that are well-known and work at least 99.99% of the time.

So why is it possible nowadays to write a mostly new piece of software that downloads relatively large files (an episode of the Rathole Radio podcast is around 55 MB, on average), which are bound to take a long time on a slow connection (like a 3G modem forced to work at GPRS speeds), and not build in the capability of resuming an interrupted download?

Even putting aside the fact that a GPRS connection is not the most stable thing in the world (particularly in relatively mountainous areas), there are times I cannot justify leaving a system turned on for the several hours it would take to finish a download unless I were reasonably certain the download was going to finish or that I wouldn’t have to start over from byte zero if it was interrupted. Without that (in my opinion) reasonable expectation, I might as well not bother until or unless I could get to a stable connection to do it. And too bad if I really couldn’t get to that stable connection, isn’t it?