[Dev] Python Object Persistence
Paul Snively
psnively at earthlink.net
Sat Nov 9 20:26:38 PST 2002
Folks,
If we're investigating options for persisting Python objects and expect
to layer RDF model semantics atop those Python objects, may I humbly
suggest that some interested party please take a look at
<http://www.equi4.com/metakit> and its Mk4py interface, which
apparently includes a MkMemoIO.py class that implements IO in terms of
MetaKit Memo fields, thereby making them suitable for use with Python's
pickling module?
Alternatively, it might be interesting to attempt to write a ZODB
interface to MetaKit as an alternative to Berkeley DB.
Of course, all of this is based on the assumption that the low-level
code should only worry about persisting Python objects and that the
interesting semantics will be implemented at a higher level. I find
this assumption questionable, and still feel that Chandler would
benefit from a graph-oriented model at the C++ level, which would then
be exposed to Python. I guess I'm hoping that we can revisit the
e4Graph question, although I understand concerns about scalability
(e4Graph uses MetaKit, and MetaKit wants to be able to mmap() its
entire file, so the scaling issue is about maximum total address space,
unless you use MetaKit in a more, er, "meta" fashion to provide
metadata and transactional integrity for data that isn't actually
stored using MetaKit, an idea that I heard straight from MetaKit's
developer, Jean-Claude Wippler).
Personally, though, I'm not sure I buy the idea that a PIM--even a
shared one--needs to individually manage >2G worth of data, and in any
event, it seems like an issue that could be revisited once we had some
practical experience under our belts.
So. Is anyone in the persistence biz at OSAF willing to at least take
Mk4py and MkMemoIO.py for a spin and report on the results?
Best regards,
Paul
More information about the Dev
mailing list