FeedOnFeeds storing feed item datestamps

By default, when FeedOnFeeds polls a feed and stores new items, it will probably get the timestamp wrong – most likely in fact, it won’t get any timestamp at all. This is because FeedOnFeeds specifically looks for a dc:date element in each item. If it doesn’t find one, it doesn’t store a time or date for the item.

Fortunately, it’s a piece of cake to upgrade FeedOnFeeds to use the latest version of MagpieRSS which as of 0.7 has this rather nice feature:

You can now get the value of dc:date, pubDate, or atom:issued as a PHP timestamp (epoch seconds) in $item[’date_timestamp’].

So a quick hack to init.php and we’re suddenly storing times and dates again. Brilliant. Just a shame I can’t backdate it to items which have dropped out of feeds I’m subscribed to 🙁

Microformats and aggregation

I always hit a mental wall when I think about microformats.

I’ve just been re-reading Charlene Li’s “Structured blogging – an introduction and the implications” and Alf Eaton’s “About reviews and microformats” and I just can’t get over the fact that, as useful as it would be for specialised search engines for everyone to use some kind of marvellous microformat to mark-up the content of their reviews etc., it’s just not good enough for aggregation. I just don’t want to have to parse your content to see if it’s got a review stuck in the middle somewhere, I want all the review metadata in separate elements in the feed itself, preferably using the RVW namespace so that I can aggregate and store data sensibly and separately from, but related to, the main content.

The question Alf asks in his post is really good (I’ve only really just got around to reading it properly): is XHTML a good enough storage system?

For storage of the marked-up data as-is, alongside the content, it’s probably fine, but as soon as want to do something useful, or practical with that data, it’s not.

Ambient presence display

I want to be able to have something either on my desk, or stuck to my monitor which indicates what my current presence level is (e.g. available, do not disturb, working but please interrupt me, etc.), fed by my Instant Messenger presence.

I’ve only been able to find a single buy-it-and-go option: the Ambient Orb, which looks great but is pricey beyond belief.

The next thing I looked at (or rather, was pointed at, by Gareth) were scrolling LED signs and badges like those on digitalbadge.com (there are hundreds of scrolling LED items on eBay), but the messages on these only seem to be updateable by hand or infra-red, and my limited IR gadget experience has led me not to rely on it in any serious way.

A bit of Googling led to me what looked like a marvellous solution which used some kit from x10.com and lava lamps, and someone else’s followup on the same article which used the same x10 kit plus some different-coloured lightbulbs. Sadly, the Firecracker automation kit doesn’t seem to be available in the UK (not named as “Firecracker” at any rate), but it could just be that I couldn’t find it – the x10.co.uk website is one of the worst retailer websites I’ve ever had the misfortune to use.

Obviously there are other uses for ambient information, such as build status of your projects, outstanding priority one bugs and so on. It turns out this is called Extreme Feedback (which links to a very good article on developertesting.com the URL of which has changed and can now be found here), but again these mostly seem to use the Ambient Orb – there must be something else out there, or a kit available in the UK to help me do something like this, surely?

Nokia starts getting serious

With the recent announcements of the N91 and the 770, Nokia have shown that they’re not kidding around. They’re not in this to sell phones, they’re in this to sell mobile digital devices. It’s tempting to say “mini-PCs”, but we’re probably not quite there yet.

I’d been impressed when I read the N91 specs, but I’d missed one crucial bit of information, along with all the other amazing features like the 4GB hard drive and two megapixel camera, it has 802.11g WiFi support.

Holy. Cow.

I currently have a Nokia 6630, and it’s a pretty good little phone. I use it for calls, SMS photos and emailing said photos to Flickr occassionally. The rest of it all works (calendar, reminders, todo list etc.) but there’s nothing really compelling about it, and it always feels really awkward using it, and syncing is a dog, so I just don’t use it. Just sometimes I’ll transfer some MP3s or OGG files across and use it like an MP3 player (using the totally great OggPlay), but I only have the 64MB card it bundled with, so I’m always having to delete them before I can put more on. It’s a pain in the neck, and I’m not willing to fork out for a bigger one given that Nokia keep switching formats their phones use. When I buy a peripheral, it should be transferable.

But anyway, back to the mini-PCs (oops! ;). I hadn’t even considered getting an N91 when they come out, but was tempted to get a 770 and downgrade my phone to something a lot more basic with fewer features – the problem with the 770 of course would be the hard drive. There isn’t one. It’s flash memory all the way. Which of course, is lame (but I’m guessing necessary to keep the costs down). I was hoping to use it around the house, and taking it with me, and effectively using it as a PDA (and who knows, maybe using Skype on it for VoIP – take that, carriers! Biff! Pow! Zzzap!) and device from which I could access my main PC wherever I was.

But it turns out that with 802.11g, the N91 should be good for this as well, and now we’re talking about having a 4GB hard drive in it as well. The tradeoff, of course (because there always is), is the smaller screen, and again the loss of things like calendars, todo lists etc. which I just don’t use on phones (this is something gained by hard experience by the way – I have actually tried!). But I’m living without those features at the moment, so it seems like the N91 would be a better choice.

Obviously I’ll be affected by the price points for these devices (neither has been announced yet), but do you think that would be the right way to go? On the surface it seems reasonable to me.

I’m trying to subscribe to your brain

Leigh’s beaten me to it very slightly by making this post which explains how he wants to subscribe to an entire person’s output, and how to convert seeAlso’s to an OPML file.

I’ve gone about it a different way.

I now use FeedOnFeeds as my aggregator (having moved away from JabRSS about six weeks ago). I’ve hacked it to do FOAF autodetection of the website every time you add a feed, and to periodically check for updates. Once it finds a FOAF file, it extracts all of the foaf:OnlineAccount details, and then performs RSS autodiscovery on those pages (and in a couple of cases does some hard-wired lookups for site which I know have RSS, but not autodiscoverable from user profile pages, like Flickr and Upcoming.org).

This actually works (with the caveat that I’m not using a real RDF parser at the moment, but it’s only a small, replaceable part of the puzzle, so I’m not overly worried).

What’s really needed is a quick and simple form for people to either create a new FOAF file with their online account details in it, or which will accept a FOAF URL as well, and merge the details in. This sounds easy, but I don’t have time because I’m about to move house.

I also intend to have some kind of admin interface to this which allows me to assign OnlineAccounts to feeds I’m already subscribed to, like adding Russ Beattie’s Flickr account details to his weblog details. This data would all be kept privately on my server of course – if someone wants to expose all this in a FOAF file, they can do so themselves.

I realise that in effect, this means making a (limited) FOAF-management tool, so I’m a bit wary of how to start. I’m not currently using a triplestore as my backend, but I suspect that as soon as I want to start actually doing this, that’s what I’ll want to switch to.

I suspect that in most cases, I won’t actually want to merge a person’s feeds together (because most of the time it’s pointless – who wants constantly updating Audioscrobbler details cluttering up their valuable aggregator space?), rather the facility to switch between viewing a list of directly subscribed feeds, and a tree of authors which expands to show which feeds they produce. Probably. This is all just guesswork because I’m not there yet, but that’s where I want to be by the end of July; I’ll just have to see if I can fit it all in.

Web aggregators and favicons

One of the nicest things about Bloglines is that it uses site favicons to display the list of feeds in the left-hand frame. Very nice it looks too.

There are three free self-hostable web aggregators that I know of: FeedOnFeeds, Lilina and Gregarious. All of them try and retrieve a site’s favicon by finding the URL of the website the feed describes and pegging /favicon.ico onto the end of it.

Whilst this is a reasonable attempt, it’s not great, and will only give about two-thirds of the favicons you need.

If you don’t find a favicon at FeedUrlReference/favicon.ico you should also:

  1. check to see if a favicon exists in the base directory of the site you’re looking at (e.g. if FeedUrlReference points at www.example.com/myweblog/ and there isn’t a www.example.com/myweblog/favicon.ico then you should also check www.example.com/favicon.ico)
  2. run a couple of regexes on the FeedUrlReference to see if it uses the <link rel="shortcut icon" href="UrlToFavicon"> syntax (or the less popular <link rel="icon" href="UrlToFavicon"> which also gets used)

Is this too much work just to get a nice image in your aggregator? I don’t think so, which is why my hacked copy of FeedOnFeeds now does it (with proper caching, too, as opposed to at the weekend, when it ran wild – sorry about that)