therning.org/ magnus

With Python being dropped as a language for extensions in epiphany 2.28 I needed to replace epilicious. I tried writing it in JavaScript (seed was integrated in 2.28), but I gave up due to hitting too many hurdles on the way. Instead I decided to rewrite epilicious using Vala and a minimal layer of C.

It turned out to be very doable, despite epiphany’s extension API lacking Vala bindings (Cosimo Cecchi, I’m looking at you ). Basically I did the following setup:

1. Add the extension following the instructions in Writing Epiphany Extensions by Adam Hooper.
2. Add a check for valac in configure.ac.
3. Add a rule in the extension’s Makefile.am to generate a C header file for all the Vala code, for use from C.

Then I started writing the actual extension. I did the minimal amount of work in C, trying to escape as soon as possible into Vala. In the few places I needed to call from Vala into C I would declare a delegate in Vala, and pass a function from Cⁱ.

I call this new version BMS, for bookmark synchronisation. I have a patch for BMS that applies to epiphany 2.28.1. (The file also contain a PKGBUILD in order to delight Arch users )

I should probably point out that while epilicious never could be called polished, BMS is even less so. I might find the time to make it multi-threaded, so that it’s possible to do some sort of progress dialogue, but don’t hold your breath. In the back of my mind is also the thought of rewriting it yet again, in JavaScript/seed.

1. The format of .vapi files are unknown to me, and I haven’t managed to find much documentation. Using function pointers seemed like an easier way, especially given that I needed this in exactly 3 places.[back]

I’ve just finished pushing support for diigo as a backed for epilicious. For the impatient there is the epilicious darcs repo. The patient will wait for the next version of Gnome to be released.

I was getting too many reports of problems on using epilicious together with del.icio.us. What finally did it was Gnome bug #491977. The patch provided was applied in the 2.20 tree. In the current development tree I simply removed support for del.icio.us alltogether. It’s just not worth the hassle!

It’s just somewhat unfortunate that the name of the plugin doesn’t fit that well anymore.

Yesterday I received my GNOME SVN account, and today I made my first two commits for epilicious, 1499 and 1500.

My epilicious.dev repo now has changes adding support for ma.gnolia. The configuration dialogue is modified to allow changing between the two supported backends.

Furthermore my APT repo holds an updated version of epiphany-extension-epilicious-pre that can be installed alongside the GNOME version of epilicious that comes in epiphany-extensions. That is, it can be used with Epiphany 2.18 from Debian experimental.

As always, comments and bug report are more than welcome.

As I’ve said before del.icio.us is not easy to program against. Here’s a brief recount of my latest explorations into how to program against del.icio.us.

I received a report about some problems with epilicious, to which I responded with a pointer to my post about my past experiences. In response I got a suggestion to pick apart the “official” Firefox plugin for del.icio.us. It turned up some interesting details. AFAICS they are using the API in an undocumented way!

First of all every single request is a POST rather than a GET. The data they send is _user=<cookie>. That cookie is retrieved from Firefoxes cookie jar; it’s set after the user logs in at https://secure.del.icio.us/login. Apparently this allows them to use cookie:cookie as the username and password for Basic Authentication. Also, every request has src=ffbmext1.4.27 as an argument in the URI (1.4.27 is the current version of their plugin). There’s also an undocumented “function” for getting only the hashes of the bookmarks at https://api.del.icio.us/v1/posts/hashes?. The maybe most interesting detail is that they don’t seem to bother with the threat of throttling at all!

Hopeful that this might offer a way around the increasingly erratic behaviour of the API I played around with python. No luck though! A few hours of investigation, some quick hacking and long testing (once you’re throttled it takes a LONG time for del.icio.us to let you back in, sometimes more than 10 minutes!!) later I found myself not being able to hold back on profanities. The API usage description is a joke! Programming against something like that is little better than programming Windows based on MSDN

It seem the official plugin can get away with disregarding throttling because all interaction with del.icio.us happens with user interaction between each call. It takes a very fast user to trigger the throttling.

I can understand that del.icio.us wasn’t designed to be used a base for synchronising bookmarks, the throttling clearly shows that. However, one second between requests is not enough to avoid throttling and there is no indication on how long one remains in a throttled state.

This exercise has pushed me to put more energy into looking for alternative backends for epilicious. So far ma.gnolia seems good and I’d like to add support for Google bookmarks as well.

As I’ve told before del.icio.us can be a very fickle partner to interact with. Lately I’ve again started seeing obstinate behaviour from del.icio.us and yesterday I finally got around to adding support for ma.gnolia.com to epilicious. They support an API that is “del.icio.us compatible” (I believe there are some things missing, but everything epilicious needs is there) so adding the feature was extremely simple.

So far it’s not quite complete, there is no GUI to change the backend store you’ll have to interact with GConf directly, other parts of the GUI lie by still referring to del.icio.us even though ma.gnolia.com is being used. However, the backend is working and the only problem so far seems to be that ma.gnolia.com returns badly formatted XML at times (still haven’t investigated it thoroughly to say anything definite).

I haven’t pushed the changes into any of my repos yet. The only way to get it is by using the epiphany-extension-epilicious-pre package in my APT repo. Debian Sid users can simply install the package, others will have to use the source.

I’ve been sitting on a few changes for a while now and now I’ve finally rolled them into a release version. Get it in the normal place.

GNOME bug #352082 has been closed and Epilicious is now to be found in GNOME SVN.

The only change is the addition of a translation to Esperanto (thanks Antono Vasiljev).

In related news, it seems like Fedore might be getting some Epilicious goodness coming its way. The packager also pointed out that the utility library (libepilicious) probably shouldn’t be installed in Epiphany’s extension library. Its location is now configurable at install time.