A couple of ideas occured to me while I was driving around today (we had to see snow so we drove to Mt. Rainier today), and this post is as much to remember the ideas as it is to talk about them.

The first idea is that it would be interesting to harvest the db code from Frontier and turn it into a Python ODB, similar to Zope. The db code doesn't rely on the hashtable structure that Frontier uses to represent it's database. It just allocates and manages binary space that happens to be stored in a file. So you could just store arbitrary data and get an offset into the database file as a token.

That arbitrary data could easily be a pickle. (Mom, this is one of those weird programmer terms, weirder than most because as far as I know, Python is the only programming language that calls the result of object serialization a pickle. And now I'm sure you are twice as confused. You might as well skip this entry, it's going to be entirely technical.) (Everyone else, if I'm wrong about Python being the only language that uses the term "pickle" in the way I've described, I'm sure you'll let me know.)

You could just store pickles in the file, and build an ODB out of it.

The real masochists would port the whole thing to pure Python (the algorithm that Frontier uses is, for the most part, right out of Knuth).

It also occurred to me that much of the design issues I've had with the frontier/python integration have to do with storing points to live python objects in the Frontier ODB. Overall, I think think it's a bad idea, since the pointer is only good during a particular invocation of the Python interpreter. But I don't have to think very hard to come up with reasons I'd want to store arbitrary Python values in the database. And then it occurs to me -- don't store pointers, store pickles. There will be times wen this could be a Very Bad Idea as well, such as when the items to be stored are huge, but it should at least be possible.

To loop this all back around, it would be interesting to write a handler for ZODB to use the Frontier ODB as the backing store. I remember thinking about what it would take to make Zope run in Frontier, and this would be an interesting way to make it happen -- a Frontier Storage object for ZODB, and Zope itself running in the embedded Python interpreter.

8:18:17 PM    comments ()  trackback []