Happy Holidays, all. Here’s a status update.

Testing

The biggest change is that tests have started appearing. I’ve written some very core tests for the daemon, testing its indexing which is by far the most important part (i.e. turning on-disk storage into data structures properly).

Canto-curses is by far more complex, dealing directly with user input, so it’s started to get test coverage as well. For now it’s still pretty basic, but the trick was in the infrastructure rather than the tests itself. I’ve written a neat little fake curses bit of python that has the interesting property of being able to print a canto-curses screen in ASCII but it mostly serves to make it so that I can run a test thread with a full c-c instance running without dumping on the screen and without needing actual human interaction.

Unsurprisingly, every test I’ve written has uncovered some bad (or at least unexpected) behavior. A small trickle of fixes and tweaks has followed them, including a couple of daemon bugs that were reported, I wrote a failing test for, and fixed. Feels good =).

Indicators

A minor change to canto-curses is that the tag status line now includes a grey indicator (similar to the blue indicator for unread items) for items that have been updated, but haven’t been displayed yet. Because the new default policy is to not automatically update the screen, this lets you finish reading items that are currently shown but still know that there are updates pending for when you update (F5) or refresh (Ctrl+r) next.

Style changes

The built in style formats have been updated so that canto-curses colors and curses colors are identical, instead of being off by one. (i.e. %1 is now curses pair 1, not curses pair 0). If you’ve messed with your format strings, you need to subtract one from each color (%8 -> %7 etc.) and if you were using %1 for curses default pair 0, you need to turn off previous colors (%0 disables last color) to get back to the default, or temporarily clear it %C .. %c.

I don’t expect many people have done this, considering it’s entirely undocumented =P.

If you haven’t dug around in this, the update with the changed format strings should go unnoticed.

Feedly and TT-RSS

With 0.9.0 out, I’ve started looking at using canto to drive mobile and web interfaces. TT-RSS seems to be a natural fit here, being the sort of homebrew heir to Google Reader. I wrote a little proof of concept TT-RSS server compatibility plugin that supports enough that the official TT-RSS mobile app can read (but not write!) information from the canto-daemon.

I was about to look at the inverse (which would be using a TT-RSS server to power canto-daemon), but I was rather disappointed in TT-RSS’s client selection (Android app costs money to upgrade from a 7-day trial and other than that seems like you’re stuck on the web) and I wasn’t impressed with having to have a full web server, database, and PHP running with a domain (or dynamic DNS) just to use them either, especially when canto’s requirement are so slim.

So, instead of TT-RSS I started looking at Feedly. Feedly is nice, has a bunch of clients on different platforms (and, of course, on the web). It also has a nicer API, in my opinion, although they’re very similar. Best of all, Feedly is a free service so there’s no need to have web facing servers running yourself.

The problem here is that Feedly doesn’t offer a great way to do hands-off authentication. There are two methods. The first is one intended for a web platform and requires a user to have an active cookie, or to click around on an OAuth page like Google/Facebook/Twitter. It then pings a registered web server with token information. Clearly this method doesn’t make sense for a sync plugin but it’s obvious that this is the more supported usecase for Feedly.

The other method is using developer tokens, which is basically a way to get an API key. This seems perfect at first glance, and in fact this is what a curses based Feedly client (Feednix) does, but these keys expire every three months without warning. Ugh. It’s a simple thing to have the daemon throw a warning to a client that connects to say “Hey, your Feedly token expired! Go get a new one and restart the daemon!” but it’s really fucking annoying that it’s going to break unexpectedly.

It seems clear that Feedly is the way to go (free accounts, no setup, lots of other clients) but I’m a bit disappointed that it won’t Just Work.