Rope part 1: building a zope product¶

After some trying out of various things I've finally started in earnest on an integration of rdflib in zope. Rdflib+zOPE=ROPE... So that'll be the name. I'm not entirely sure how big a task and how big a deal it will be, but I'm guessing "moderate" and "really nice" respectively.

Being my first zope product made on the filesystem instead of using zclasses, I figured it might come in handy to write the whole process down. If not for myself, then as an addition to the list of available howtos.

So I'll try to regularly give a status update here. First time I do a thing like this on a weblog, but I'm all in for this experiment. This afternoon, I walked through the ZDG (zope developers guide), chapter three: "zope products". During this process I managed to bash together a tiny hello-world-quality program. Do this yourself, it should give you a little bit of zopy feeling in your fingers.

I probably shouldn't mention that this hello world took me two hours (including reading the chapter of course) in zope compared to the usual 0.5 to 5 minutes in other languages. But I suspect that you, honored reader, have half a hunch that spending a bit up-front costs on learning zope will reap you great benefits later on. At least, that was my thought. I'm betting heavily on it that learning coding in zope will improve my general internet-coding productivity by an order of magnitude. It's a bit of intuition. But, being a good engineer, I'm trusting my intuition.

This afternoon I also requested a sourceforge project for this, as I thought it would be something useful. Otherwise just keep it on your local harddisk. But use cvs!* You'll save yourself from the worst of accidental deletions, wrong turns taken during development and version mismatches. I've been smiling all day because the name Rope wasn't taken yet. Rdflib + zope = rope makes for a pretty well-explainable name and it's nice and short. When I thought of that name (literally after 15 seconds) I didn't expect the name to be free :-)

This evening I set up a directory at home and created the usual empty files: README, INSTALL, LICENSE, CHANGELOG. Just having them there makes it look better. I knew of some limitations (python version 2.2 or above for instance), so I put that into the INSTALL document. I copied the BSD-style license from rdflib and changed the name of the author. CHANGELOG is still empty, but I even typed in the project's goal into the README. It is never too early to start documenting. And documenting is what I plan to do well. Nothing hurts a potentially good project as much as missing or bad documentation.

Ok, back to the ZDG (for the last time: Zope Developers Guide), chapter three. This tells me to start with an interface, being a good description of the functionality of the product. Well, Daniel Krech has done a good job on rdflib and already defined it for us. He didn't actually call it an interface, but nonetheless. In your rdflib directory, look up rdflib/store/AbstractTripleStore.py. Ok, there's some implementation in there, but most of it is left blank for other impelementations to fill in.

The next step is to implement it. Well, basically we can choose the standard in-memory implementation rdflib/store/InMemoryStore.py. An alternative is rdflib/store/BTreeStore.py, which uses (applause please) the zope standalone database. Standalone in this case means that it opens it's own database etcetera, so it doesn't sound very like the automatic persistence normally enjoyed by zope products. I tried rdflib's standalone zodb storage and it works very well. But for the moment I'm going to bet that the in-memory storage will be just fine, as zope should be able to store that in-memory thingy automatically just fine. I'll leave optimising to a later stage.

Well, enough for one evening, I'm going to take a shower and snuggle up to Annie :-)

See the permanent status page