Everything old is new again.
Why not publish in PDF if you’re going to go against the web’s grain anyway? That gets you frictionless publishing tools.
Also see Gareth’s Textify! Greasemonkey script which restores the content to actual text rather than an embedded image. Nice way to really show how much you hate the web, Hammersley!
The RSS wars are back and if someone’s not careful, with the resignation of Dave Sifry (and potentially others) from the does-it/doesn’t-it exist RSS advisory board, they’ll be in full swing in just a few days.
It’s so sad just to what extent RSS is now just damage to route around.
FeedThing is a desktop aggregator written in C++ by Gareth Simpson. The internals are split into several parts, including libfeedthing which is the core liberal feed parser, but it hasn’t been updated for ages, and I don’t think even he uses it any more, so it only supports the interim (and deprecated) Atom 0.3.
Which is a shame, because if was still using it, it would probably have a working Atom 1.0 parsing library.
As far as I can tell, there isn’t a single open-source Atom 1.0 parser written in C++. Unlike Java, Python, PHP, Ruby and .Net which all have it good with at least one solid feed parser.
I want a proper parsing library for my Atom-over-XMPP application. I’ve just been upgrading Feed On Feeds to transmit Atom 1.0, so now I need something to receive it – so far this has been FeedThing, but I don’t really fancy upgrading it to support Atom 1.0. The obvious alternative is to pick an open-source desktop client which already supports Atom 1.0 or could do by upgrading the parsing library it uses, and use that instead, but the only one that meets the “appealing” criteria (see below) seems to be Pears, which is a wxPython application (nice and cross-platform, and the xmpp libraries and code samples already exist) but that seems destined to move to an HTML interface in a desktop frame, which doesn’t sound particularly pleasant, and frankly, having actually now used it for five minutes, I already want to jump out of the window just to alleviate my suffering.
So what shall I do? I suppose it would be good for me to write some C++, but ditto with Python, and I have been wanting to do some RSS/Atom integrating with WikidPad – maybe this is my cue?
Those “appealing” criteria in full:
- desktop aggregator
- not .NET
- not Java
- three panes preferred
- allows nested folders in the feed list
- easy to upgrade to support Atom 1.0 if it doesn’t already
- XMPP libraries in the aggregator’s programming language already exist (and work!)
- must run in Windows (cross-platform a plus)
Of course, when I say “appealing”, I mean “non-negotiable”.
For a larf, I added two quick hacks so that my Feed On Feeds installation now outputs my feed list in three formats:
- My subscription list in OPML (which comes with Feed On Feeds already)
- My subscription list in XOXO
- My subscription list in Atom
- Generating the OPML was easy, but despite its ubiquity, I have no idea what will and won’t be able to read it.
- Generating the XOXO was harder, there’s no hBlogroll microformat, so I’ve just copied bits of what Les Orchard has done, and no aggregator tools will be able to use it.
- Generating the Atom was mostly easy, but mandates an
entry, which would need a query the other two don’t and I needed to ensure that if there wasn’t a feed description, that I was generating something else in order to fill the mandated
summaryelement. Also, no aggregator tools will be able to use it for importing a list of feeds.
- My OPML might be able to be imported by other applications. Marvellous!
- My XOXO file can be displayed on the web straight away, as-is. Marvellous!
- My Atom file validates, so can certainly be parsed by any tool that understands Atom. Marvellous!
Subscription lists, three years on from when I first started using them, are just as crap as they were back then. If I were a tool writer now, starting from scratch, I’d be exporting and importing subscription lists in the form of Atom files. Any tool that wants to understand that file can transform it into whatever bastardised version of OPML it understands. I will definitely be adding Atom feed list import to my copy of Feed On Feeds.
On a related note, a few weeks ago Danny Ayers was talking about using del.icio.us for reading lists and in November Aristotle Pagaltzis published an XSLT for converting from del.icio.us API results to Atom.
I’ll leave you to join up the dots.
Not that PalmSource aren’t entirely dead anyway, but they recently announced a “commercial-grade Linux-based platform designed for smartphones and mobile devices” called the ACCESS Linux Platform (ACCESS being the Japanese firm which bought PalmSource in December 05).
The interesting highlights are:
- using SQLlite for data storage, which should make 3rd party integration easy
- using GTK+ for the UI (just like Nokia with Maemo)
I don’t think I can even remember the last time I saw a Palm-powered device (other than my unused Clié, under my desk).
I was reading the other day about how futurologists get it wrong and how we’re never going to see an Internet Fridge. Well goddamn if I don’t want some variation on that.
How much would I give for the ability to scan the barcodes of stuff I put in my cupboards and fridge, then scan it again when I remove it, and so be able to call up the list of what’s currently in my kitchen when I’m at the supermarket, or have it automatically remind me when I’m out of something, or running out, or, from a pre-defined list, auto-create most of my shopping list. I mean, how hard can that be? The hardest bit (by a country mile) is getting the barcode scanner to understand what item you’re swiping in front of it, the rest is “just” programming (and let’s face it, if I can do it, it can’t be hard).
I’ve been interested in XUL for a long time. Or, since 2002 at least.
In fact, although I’d forgotten all about it, many years ago I put together an alternate homepage for this blog which used XUL so that you could navigate information which I didn’t want to have to manage or reproduce in my main HTML page. It doesn’t really work any more, but it shouldn’t be hard to fix, if I had the inclination.
What really brings this up is the recent stable developer preview of XULRunner. XULRunner has been promised for years, and it’s really good to see it reach maturity as I’d really given up hope and stopped following its progress (or that of a GRE) a long time ago. You can check out what XULRunner provides and see that it gives you full programmatic control over almost anything you might want to do that Firefox can already do (like rendering SVG; displaying options windows and saving those options; open, edit and save files, etc.) and that it will allow you to embed these features into your existing applications using JavaXPCOM (embedding bindings for Python, ActiveX, GTK and NSView are under way but not yet complete).
XULRunner is an important piece of software as it allows you to install multiple XUL-based applications (say, Firefox and Thunderbird) but only one core XUL platform, thus reducing the size of each of the separate installers appropriately. Indeed, when it reaches 1.9, it will be the default application launcher for Firefox.
Anyone wanting to get started developing with XUL would be best starting with the tutorial on XUL Planet followed by the links on the XULRunner page on developer.mozilla.org. If you didn’t already know, tools like ActiveState’s Komodo (a cross-platform IDE) are based on XUL and work extremely well, so there is already precedent for people creating these types of applications, they just don’t get much visibility (yet).
Ages ago I wrote a post bringing light to a bookmarklet attached to a bug in Mozilla’s Bugzilla which allows you to export your Firefox history to a text file. According to Google Analytics, it’s far and away my most popular post, but the code doesn’t work in Firefox 1.5.
People have been commenting on the post and sending me mail asking for an updated version which works in 1.5, which I keep meaning to look at doing, but the new Places bookmarking and history system based on SQLlite has just been enabled in the Firefox nightlies.
This means not only a new way of storing the data, but new ways of querying it, either via Mozilla like we do at the moment but with a new API or by a third-party application so long as it can understand SQLlite, and there are plenty of bindings to do this.
So this should mean that Firefox 1.6 has an entirely new backend for history and bookmarks, at which point writing new code to export the history should be very easy, and I’ll do it then (if someone hasn’t already beaten me to it).