So, a Sauna Sprint is happening again. Here goes for sketching. A suitable location for up to 12 people is booked, but upon interest this we can extend up to 15 people.
Cost of accommodation will be 30€ per person per night. (Plus food and drinks.) Bed linens and a sauna towel will be provided. This can still end up being lower if I sort out any sponsorships. Should any GSoC student-mentor pairs attend, we can sort out a special rate for the student.
The venue is about half-way between Helsinki and Tampere so it's within about 1h 40min (by car) of two airports.
The sprint topic is at this point planned to revolve around polishing the pip installability story of Plone and bringing ZServer into the future. It'd be nice to have a smoother entry funnel for non-Zope-background Python developers into Plone. I'm open for countersuggestions on a topic.
Please indicate your interest / preliminarily confirmation of participation, so I can determine the feasibility of the event. The tickboxes have 3 states, one has to click twice for a maybe. https://doodle.com/poll/wdepr8bn6w3rkrst
As we should know, Plone can already be installed and add-ons developed with pip, but the experience could be smoothier (merging pip-compatibility to z3c.autoinclude, removing includeDependencies from core, fixing hardcoded ./etc/site.zcml path from Zope2, finding new place for helpers in plone.recipe.zope2instance).
The current ZServer will not be ported for Python 3. Yet, some of us depend on asynchronous features provided by asyncore. The goal is to implement replacement for ZServer by using some existing Python 3 asyncio HTTP server, possible aiohttp. In addition to async tasks we would gain websockets support for Plone.
Not so fast. We can have nice things on Plone too. We've been using asyncore based async tasks (collective.futures) with Plone from 2014 and decoration based (ZCML-free) component configuration (venusianconfiguration) since 2013. And we almost had websockets on Plone already in 2013 (collective.zws).
That three column listing is loaded live from external service (with one minute ram caching). The requests fetching the data are made asynchronously and Zope worker threads are free for other request during fetching.
That contact search calls external LDAP service for search results.
SOLR search. Complex multi-collection SOLR searches can sometimes be slowish (especially when there is on-going indexing slowing down the cluster). We use collective.futures to make those calls in non-blocking fashion.
Finally, a one more involved experiment with similar tech: https://github.com/datakurre/collective.jazzport can create large ZIP files from Plone in non-blocking fashion. It collects URLs for the included content, then frees Zope worker threads, and finally downloads all the files for the zip file through HTTP from the same Plone in multiple parallel threads. That's fast, because after traverse Plone can stream blobs in non-blocking manner.