Plone 6.0: What I expect¶
We’re still working on Plone 5.0 but for PLOG 2015 I put all my thoughts together and want to share with you what I expect Plone 6.0 to include.
Legacy, redundancy and why forcing a style guide¶
Plone has a lot of legacy code and this results in several different ways of doing things. Some developers prefer the old style some try to figure out a new way. Since we had no style guides in the past (we’re working hard on that) it was up to the developers themselves how to implement a piece of code.
This should definitely be past in Plone 6.0. Code which is not aligned to our style guide should not be allowed to be committed or merged, several other open source projects are very restrictive here and we can learn from them a lot.
Indexing, information retrieval and why we should drop ZCatalog¶
First of all, I like the simplicity of ZCatalog. But if you have big and more
complex projects, ZCatalog is a huge pain. First pain on a heavy load site are
conflicting writes on BTrees in the indexes - this kills speed. Why do we use
portal_catalog? Yes - of course we want to speed-up things, so this is very
contra productive.
Second is more a rhetoric question - did you ever use Solr and why did you use it in combination with Plone? Of course because the old ZCatalog does not provide you state of the art information retrieval techniques as Solr ships out of the box. Stemming, Synonyms, Stopwords, Language and text analysis tools, scalability, replication, etc. etc.
To be more clear: if Plone does not integrate Solr (or other state-of-the-art search engines, Solr was just a very common example here) in future releases, we will stop to use Plone!
If we want to call ourselves “Enterprise CMS”, this is from my point of view a MUST to stay alive.
BTW, i’ve released collective.recipe.solrinstance a few weeks ago which supports Solr 5 out of the box.
Authentication providers and why we customize this on every project¶
Did you ever customize Plone’s login form and password reset stuff? Really,
for me it looks like 99.99% of all Ploners do so and this is the most
legacy component we have.
That’s another blocker for me, if we don’t fix up the login topic to be more customizable, we should not be allowed to call ourselves an “Enterprise CMS” system. Plone still can not act as an OAuth Server and we don’t even have OAuth client integrated into the core.
BTW I’ve started working on some OAuth stuff, but got lost in the
PluggableAuthenticationService, Zope 2 Request and Session hell so
i postponed this, see pas.plugins.authomatic where I wanted to use
Authomatic to not reinvent the wheel for OAuth.
My AngularJS frontends and the missing API¶
We recently developed a huge e-commerce system built on top of SAP, Plone and MSSQL with data preparation using RabbitMQ. We used a lot of applications, technologies, techniques and services as RelStorage, horizontal scaling of Zope 2, haproxy, varnish, memcached and nginx on the front.
But what we had to built ourselves was the overall missing API for the AngularJS frontend.
Whatever you’re using to build your frontend, you’ll always have to talk to the backend using an API. If Plone would ship one we could extend, this would make our all daily business easier.
Authorization and Zope 2¶
We should be able to replace Zope 2 with other state of the art application
servers. But this opens a new problem regarding permission and rights system
we reuse and extend this from Zope 2 components. We’ll need more discussions
and some Zope experts here to go deeper into this, i can just point on the
current implementation and say, we need more flexibility and scalability,
higher performance and a built in REST API would be great.
Persistence layer¶
ZODB has bad performance on high write concurrency. The main reason are restarted transactions because of ConflictErrors. Ok, after some debugging i figured out that the catalog is responsible for most of the ConflictErrors and this could be fixed if we replace the catalog, but even if we use RelStorage we have very ineffective storage of information, this could be done better by implementing a new RelStorage adapter which does not just store pickled objects and reuse database specific features as indexing. I think we may learn from Kotti here.