It appears everything is going pretty well with the new codebase, there’s been a dearth of real bugs (and one aesthetic one). I’m chalking that up to lack of adoption however as most of the emails I’m getting (one or two a month outside of the tracker mails) are still about old versions in Ubuntu and Debian repos.

Or my code is fucking perfect. You know, could be that one too, right?

Anyway, with a lack of bugs to distract me, here’s what I’m looking to add to the next version of canto-curses and, if necessary, canto-next.

Old Canto look. This one’s done and in the git right now at the request of langner, it adds the old school borders to tags. The cursor behavior is already present and I think all the other interface foibles are either irrelevant or already handle-able.

Polish. There are some operations that are currently bulky, or return unwanted output (like canceling an input with Ctrl+g can sometimes throw a pointless warning message about unparseable output). I’d also like to simplify use of manual tagging.

Documentation. The plugin and theme docs are currently non-existent which is a shame because both of those systems are integral to the design. Unfortunately, docs also mean that the interfaces have to be standardized and examples drawn up so I’m not looking forward to it.

Future concerns:

Tab completion. I was disappointed that the initial release didn’t include this, or at least some form of history, but readline in Python with curses doesn’t seem to be a well-trodden path and I’m sure as hell not home-brewing it unless I absolutely have to.

Memory usage. canto-daemon still uses more memory than I’d like. All of the information clients query from it is on-disk and as such it should be possible to strip the memory usage down to nuts and bolts, but then of course you pay a disk performance penalty every time you grab new data. There’s a middle ground somewhere in there, likely stripping the resident content down to a smaller subset of the XML, so stuff like getting larger item content (reader) will be penalized with a bit of IO but just populating the feed list won’t be.

Sync. I’m against writing a Google Reader plugin, though it should be relatively easy with the daemon plugin capabilities, because the API is unofficial. I would like a solution for people that use multiple boxes that’s a little more elegant than requiring an rsync but we’ll see.