Conclusion

What have we got?

Now our Plone content is actually mirrored to a database, in near-real-time.  Pretty cool.  (You can actually watch it happen, if you run Plone with instance fg.)  We can query the content via anything that can access a PostgreSQL database.

Also, we can view (sort-of) our Plone content via Django's admin interface.  If you just need proof-of-concept, here it is.

What's next?

We do not have a full-featured Django web application.  Django does not have any of our workflow or permission definitions from Plone.  Nor do we even really have a proper way to display Plone content items.

Further Observations

It appears that ContentMirror is designed to work with a single Plone site. This one-site model will cause me a bit more work, because the name of the Plone site is not exported with the content, AFAICT.

I tried installing plango, the Django app for serving Plone content, since Andy did so much work on it. I found that I had to hack a ton of it to remove search-specific code that requires Postgres 8.3 (since i'm running 8.1.18). It worked OK, but not spectacularly. When I realized it uses the GPL 3 and I'm not sure I have approval to go GPL myself, I had to yank it entirely.

My next step will be to try another Django-based CMS, like django-cms. I don't expect to serve the exported atcontent data directly. Instead, I expect to write some migration code that converts from the AtContentTypes models into django-cms content type models.