974 words on Software
My main gripe with many of the second web sites is that they encourage you to enter you data and then just keep it without giving you an (easy) option to export it and take it elsewhere. This is where sites having APIs that actually give access to your data and are reasonably easy to use come handy. delicious one of them, and I started finding it much more useful once I saw that there are a number of tools which simply let you download your bookmarks.
Cocoalicious is a very powerful such tool which is cool if you want to edit your bookmarks. But usually that’s not what I want to do as my idea of delicious is more along the lines of 1) Hit the ★ link in my Safari bookmark bar to invoke the delicious bookmark script, 2) add a snide comment to the link and quite possibly 3) throw in some random tags. No editing needed there. I.e. Cocoalicious is a bit too powerful / bloated for my needs as I’d just want to mirror my delicious links locally.
To be honest, ideally I could see myself appreciating my Safari bookmarks and my delicious bookmarks being properly synchronised. But I am not even sure whether the iSync architecture and the delicious API would be up to that; or how the comments and tags would be stored in Safari bookmarks. Besides, it looks like actually writing a iSync plugin is quite strenuous (how many iSync plugins are there?).
And thus I have been a big fan of the delimport utility for a long time. It’s a background application that polls delicious every thirty minutes and stores a copy of your bookmarks locally. It also comes with a Spotlight importer which means that I can actually search for links by the snide remarks and useless tags I gave them. Unobtrusive, lean, neat, just my type of thing.
Unfortunately that didn’t work. Somehow the CURLHandle framework used by delimport to handle the downloading wasn’t available in a Universal version while looking rather abandoned as far as development went. To me it looks like the problem came from commands run in some build-phases to get the linking right, which failed for Intel (or so). I.e. a problem which I didn’t even understand properly and which I couldn’t fix. Back then I gave up and settled for making delimport’s Spotlight importer universal because Spotlight importers needed to be native to the processor to work at the time (I think by now Spotlight will be smart enough to just spawn Rosetta based importing process if PPC importers are to be used, but initially it didn’t).
But eventually I realised that probably that framework was only used for downloading and that in principle Cocoa’s classes should be able to do that as well. So, recently, I had another look at it, kicked the framework out (thus reducing the application’s size as well – it’d be really small if it didn’t contain that gigantic Keychain framework which provides all or at least loads of keychain related features when we all we need is getting or setting a password) and replaced it by some of Cocoa’s methods.
A bit of extra tweaking (delicious wants you to send a non-generic User Agent string; occasionally the server connection just fails these days and gives a zero-length response but no error, which was worth working around) later, the tool worked natively on Intel and I have been running it on my machine for a while now.
But what next? I thought it’d be a good idea to ‘contribute’ the changes back to the project. But I didn’t manage to successfully contact the original author so far. Not that I’m particularly keen on that open source stuff – people might dare to criticise my incompetent work after all or question the necessity of throwing in some localised strings so a
Don't can become a
Don’t – but giving back those changes seems like a good thing here.
Finally I have to remark that at first I was shocked by what delimport actually does: It checks whether there are any new changes to your bookmarks on delicious and if there are it downloads all of your bookmarks. That easily amounts to a multi-hundred kilobyte download every single time you add a tiny new bookmark. Which seems clumsy and excessive.
I had a look at the documentation for delicious’ API to see how this could be improved and it turned out that the API is so weak that this method is the only way to do the job properly. None of the other API functions let you see whether old bookmarks have been edited or deleted. Only getting the full set of bookmarks and comparing them to the set you already have will be up to that job. And while I’m a fan of efficiency, I’m an even bigger fan of doing these things properly and keeping the local copy of the bookmarks as synchronised as possible. So delicious will have to shoulder those additional downloads.
So, um, is it downloadable somewhere?
In the (un)happy coincidences department, I noticed that my Leopard installation seemed to break delimport on my PPC machine, so I was going to download the source and try rebuilding it in XCode 3.0, and while I waited the requisite 20 years to build darcs and all its dependencies via MacPorts, I decided to do a Google search for “delimport leopard”, and your post was the top hit. ☺
Well Google is quick then.
I’ll send you a link to the current state of affairs for testing.
Hi there - I’m the guy who’s taking on API development for delicious.
Synchronization is actually something I’m working on right now, along with developing an entirely new API revised from the ground up. We’ve got some experimental sync work in the v1 API to enable our Firefox bookmarks extension, but it’s undocumented and not in any finished state I’d feel comfortable supporting for developers in general. For the next gen API (or maybe even finalizing the v1 sync API), I’d welcome any suggestions you have.
l.m.: Great to hear that there are plans for synchronisation.
As I haven’t done any work in this area before, I don’t think I’m in a good position to give any advice. All I can do is say which additions I would have considered convenient for the task delimport does: The main thing would be a way to get all changed bookmarks since a given date. That way updating the local bookmarks would result in a small data transfer only as that method could be used instead of downloading all bookmarks.
If, in practice, the format remained the same, it would be very easy to upgrade applications accordingly. (I don’t really like programming, so I’m regularly appalled by APIs being all bloated and complicated rather than giving you straightforward access to the data. Just try making a screensaver with images from a flickr photo pool to see how things can be all bloated, horrible and not particularly useful.)
And as you’ve been asking, I am wondering whether you have stored the last changed date of a bookmark as well. I can give the local files representing the bookmarks a creation date that’s the creation date of the bookmark. It’d be cool to be able to set a correct modification date in the same way, which currently isn’t possible. As in practice people mostly display the modification date but not the creation date in list view, the modification date is much more useful, but I’d feel bad to just set it to the bookmark’s creation date because that could be wrong.
By another strange coincidence I’ve just finished reading this by another delicious dev