
On Jun 24, 2011, at 7:51 AM, Barry Warsaw wrote:
As long as Pipermail is still in the core, I do think it makes sense to continue the work to port it to Storm, since that's the ORM that the core uses. We've talked about splitting Pipermail off into a separate sibling project (much like the new UI is currently), and if we do that, I'd be open to re-evaluating the choice of Storm for Pipermail.
I don't want to throw a monkey wrench into Andrew's work of course, just saying that if there was compelling reasons to want Django and its ORM for Pipermail, the way to do it would be to split off Pipermail first.
Cheers, -Barry
I agree that the preferred design approach is to split the project into a number of independent modules that communicate through traffic queues / channels and a database which stores the settings.
I don't know that much about the various ORM schemes. Could someone explain why the STORM is preferred to the Django ORM or that used in Pylons?