Ramon Navarro Bosch: plone.server

plone.server is just a project, it is not approved by the framework team, this is not in Plone core yet.

Philip Bauer in Brazil Plone conference 2013 was pushing people to think about the future of Plone. Where are we going. Plone has a really good component architecture, thanks to Martin Aspeli and others. After lots of discussions about the future in Bristol Plone conference 2014 Timo Stollenwerk started working on the Plone REST api. Asko Soukka worked on Mosaic. Nathan Vangheem worked on elasticsearch. Eric Brehault worked on front end with Angular 2. We took lots of these people and gathered them in Barcelona earlier this year. Fifteen developers on back-end, api and front-end. Experiment: could we do it? Yes, we had really great results. We have reached an experimental version of the whole stack. We will present this today in three talks.

In this talk: the back-end.

We split the various parts of Plone in three: front-end, basic core (dexterity, zodb), extra Plone stuff (link integrity, discussion). The division between the parts is bridged with a REST api and the framework api (plone.api).

Possible future is that plone.restapi will be included in Plone 6, and separate front-end is possible in a later version.

For plone.server we used as base ZODB 5, ZEO asyncio, and the ZTK (Zope ToolKit). It is an asynchronous app server that offers a traversable REST api with a ZODB.

It is a headless CMS: it does not include the view/presentation part.

Content type: there is no CMF, it is based on zope.container and dexterity. One content type: an item that is a container. Content types are specified declaratively, defined in Python code and zcml, not stored in the database, no option to create content types through the web at this point. A simple base.

plone.jsonserializer. Used on plone.app.mosaic. We need to merge this with plone.restapi. We did fixes yesterday night.

plone.registry is the main or really the only configuration place. All persistent info is in one place. For example portal actions should be in the registry.

API definition. Traversal is hard to define in an api, we used json. We use the websocket api. All is built on plone.restapi.

Mount databases or sites using json configuration. /DB/SITE/FOLDER/OBJECT.

In traversal we do a lot:

• Get the resource
• abstract the user
• language negotiation
• check access permission
• etc

Read calls (mostly GET) by definition do not write anything to the database. Any changes are rolled back.

On the request we make available several things like the site components, the main object, configuration registry, etc. Some helper methods. Upload/download is done with external blobstorage with async.

There is no ZCatalog, but there are ways to hook up what you want yourself. No GenericSetup, no acquisition, no z3c.form, no attribute traversal. No Zope roles, only Plone roles or permissions. The base Plone server does not need many packages outside of the ZTK.

It is Gunicorn compatible (WSGI). It is only for Python 3.5 and higher.

Extra packages: pserver.oauth, pserver.elasticsearch, pserver.gcouldstorage, pserver.cms.

You can try a demo with the repository at https://github.com/pyrenees/pserver.demo

We are a community! We can have fun! We should be proud!