POOP / Python (Object Oriented Persistence) ?

[Tony J Ibbs (Tibs)]

OK - I spent some of my "spare" time last night reading

http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

and also Jim Fulton's Introduction to the Zope Object Database (referenced
therefrom, although I found it by other means first), and also with a quick
look at the ZODB How-To.

Gosh. Damn time machines have been at it again. Ask for something and it
will have been there.

The PJama (persistent Java) people regard a mainstream persistent language
as a killer-app, allowing a major revolution in how people program. It's the
sort of thing that I find quite exciting, because it's a different
programming paradigm - no more worrying about database startup/shutdown,
crafting little save files, etc. And yet here is Python with ZODB which
looks like it does a good part of what the PJama people are aiming at (as
Martijn said a couple of messages ago), and I hadn't really heard of it.
Well, I knew about Zope, and about pickling, but that's not the same thing
at all.

I need to go back and look at the PJama stuff a bit next (although a quick
look makes me wonder if any work is progressing on it - all the dates look a
bit old), because I only had vague understanding of it, but here are some
uninformed musings:

The persistent Java effort requires quite a lot of work in the innards of
Java (i.e., C++ programming). This is presumably because Java doesn't expose
its insides to introspection in the same way Python does (Zope does use
vanilla Python, doesn't it? Can it work with JPython? (I assume not)). This
is obviously a disadvantage for the PJama people, not least because of the
licensing terms around Java (i.e., why they can't call their variant pJava,
even though they have had funding from Sun).

Glasgow has a lot of interest in distributed objects, etc., so they've also
put a lot of thought into how that works in the persistent arena. Obviously,
ZEO is a step in that direction, providing the first mechanisms needed
(makes sense!). Given the Python world, I would believe that it will expand
to cope with any problems that crop up in a practical manner.

Versioning and cache management is a Good Thing, and it's there - from a
superficial reading it sounds like the hooks are similar.

How easy is it to write a storage manager? It sounds to me as if this would
be a useful thing to layer on top of a COM or CORBA interface to (for
instance) an existing GIS, taking advantage of whatever versioning, locking,
etc., that that existing software provides.

Snags.
Well, it's obviously a bit of a pain if __getattr__ and __setattr__ are
unavailable for easy use - although I can't say I've used them for anything
significant myself, they're useful tools for the back pocket.
Also, the "lists and dictionaries aren't classes so we have to prod the
persistence when they're altered" thing is a slight pain.
And I know I've had problems getting to grips with pickling - although that
was my fault 'cos I *was* trying to do something odd.
But I can't think of any SIGNIFICANT problems from what I've read. And I
know I'm itching to try it (maybe I'll finally get round to cataloguing our
book collection again...)

So, why isn't this better known? Is it just that Python is too good at too
many things? Maybe we need a page of "clever things Python does that other
people think are hard", or "important buzzword compliances by application",
on the PythonLabs site...

[It would help if this was all more evident from the Zope site, as well,
though. Talk about hard to navigate round.]

Tibs, all excited again

[Hmm - should CP4E be considering what happens to programming if people
*start* with a persistent language?
	"""*My* variables last longer than *yours*."""]

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.demon.co.uk/
"Bounce with the bunny. Strut with the duck.
 Spin with the chickens now - CLUCK CLUCK CLUCK!"
BARNYARD DANCE! by Sandra Boynton
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)