Storage

The next logical step for Straw in terms of features would be storage of items locally. Or at least the storage of information about what has been read, but I'll probably go for local storage of feed items because I think it won't be much more difficult.

However, I'm a bit unsure how to go about this. ZODB would be a logical choice in many respects: it would allow me to store relatively painlessly the object structure without me having to do very much at all. Patrick Logan believes transparent persistence isn't usually needed or practical for real problems , but I believe it would suit this case pretty well.

There are two problems with ZODB, however: it apparently isn't very compatible with Python 2.2 — but this might be circumvented with a new enough version and by not using new-style classes, I believe — and it's yet another dependency, this time with a library that pretty much no-one will have installed already and which might require fetching from CVS. I usually don't mind dependencies, they just indicate healthy code reuse, but in this case I'm a bit unsure.

The other option would probably be Sleepycat's Berkeley DB 3. Many/most people already have this and if they don't it's probably easier to install. But I guess it won't be as neat a fit as ZODB, requiring more manual mapping back and forth from my code. Obviously I'd love to avoid that if possible :-)

As you might have noticed, I don't have quite all the facts I need to make an informed decision. ZODB being part of the Zope family, I'm not sure how easy it'll be to correct the situation — the documentation can be sometimes hard to come by. That's likely to be one thing that won't be a problem with DB 3.

Time to find out about the state of the art of this persistency thing.

It's release season

Straw is now at version 0.5.

New Straw

A new version of Straw, again. Version 0.4 features a code base I'm somewhat satisfied with, some new user interface features for navigating the items, and probably a whole lot of new bugs and regressions.

There's still some ugliness in the code but I don't think anything too major, so I might be able to focus on new features now, unless I detect some major breakage.

Any loser could make a better browser than this, right?

An excerpt from an interview with Chris Blizzard:

Q: What's been the hardest thing about working on this project? A: Imagine a four million line code base that is based on C++, uses threads, a hundred shared libraries, and is over a gigabyte in size when built and then point a debugger at it that was designed to debug GNU sed.

Gooed Symbian

Chris Double has provided the first reason I'd almost — if it starts working some time in the future, I'll change that to really — like to have a phone running Symbian.

So many books, so little capital

On Patrick Logan's blog, I just saw this note about corporations as a remnant of the feudal system, with a link to a review of The Divine Right of Capital by Marjorie Kelly. It sounded very interesting — I go for a lot of that kind of stuff — so I checked out how much it would cost.

On Amazon, it's pretty ok: $17.47 doesn't sound too bad. On Akateeminen, the largest bookstore chain in Finland, not so nice. I'd be quite willing to shell out a few bucks to support local dealers, but the difference between 40,60 € and $17.47 is a bit more than I'm readily willing to stomach, especially in the days of near-parity.

Of course it's not without costs shipping crates of books to Finland and keeping them in a warehouse somewhere, but still, with that kind of prices, it's hard to see how they manage to compete with web stores, especially in the future if and when more people have the means and ability to access those stores and pay for their purchases. Personal customer service sure is nice, but not that nice.