Change from Zope to WebOb (its about time!)

Hi Plone contributors,

I would like to know the advantage of WebOb over Zope framework.

Thanks.

Hello Marc,

To help us (the Plone Community) a bit with our own communications about the technology stack we use: what did you find out so far yourself about the differences between Zope and WebOb, and/or what is your perception? A few paragrapgh are enough.

Then some knowledgable forum members here will surely be able to complete and correct your findings. There's a lot of information availabe online both on Zope and WebOb.

Cheers,

Fred

1 Like

Hi Fred,

after consulting the internet for Zope and WebOb, I concluded on the main difference between the two frameworks.

WebOb is wrapper of Web Server Gateway Interface (WSGI), which allows common ground for portable web applications. There is a WSGI middleware that allows requests to be redirected to the appropriate server (since the application is now portable).

The middleware also allows load balancing the requests, concurrent processing and ultimately (in my opinion) fault tolerance.

Please correct me if I have mistaken what I said.

I wrote a proposal on contributing to Plone. Can you take a look at it and give some feedback please? I suggested the add-on on the RestAPI's, which has the ultimate goal of supporting group communication and fault tolerance.

I believe now I am more eager to change the Plone server from Zope to WebOb. :smiley:

Cheers,

Marc

And where is this proposal?

-aj

oh. I thought I shared I GSoC. Nevertheless, here it is:

// https://docs.google.com/document/d/19JeFa89FAORUdVpl1PSIIc_Xfx_5UW86Bi-TQH4S7_0/edit

Feel free to give comments. Thanks.

Marc

@zopyx @fredvd

Zope usually uses "ZServer" as network interface, but there is also the option to use "WSGI" instead of "ZServer". I do not know how good the integration "Zope/WSGI" is,.

Hi Marc,

Thank you for your interest in Plone, I think you'll enjoy your stay here!

Here are a few few things you'll need to take in consideration in your research on this.
a. Current WSGI support: http://zope.readthedocs.org/en/latest/WSGI.html
b. plone.subrequest https://github.com/plone/plone.subrequest/blob/master/plone/subrequest/subresponse.py
c. Anything that hooks into Medusa, ie collective.taskqueue https://github.com/collective/collective.taskqueue/blob/master/src/collective/taskqueue/server.py
d. http://docs.plone.org/develop/plone/forms/files.html#streaming-file-data
e. Anything that uses ZPublisher.iteratos.IStreamIterator
f. API compatibility w.r.t Zope2's REQUEST and Zope3's request objects.

This is going to be the key issue in this whole project. Full compatibility is essential and hard to achieve.

-aj

Thanks for these important info! I am digging into them!

Hi Marc!

Please note that the following is not intended to attack you, I'm purely trying to be concise.

Before you dive into the deep end, what features are lacking currently in the Zope request/response objects? I'd highly recommend that you (re)structure your document a bit, so that it becomes clear to us and yourself why this needs to be done.
When is done, I'd recommend reconsidering your projected timeline. I think you'll find that three weeks isn't going to be enough.

Given that you would like to implement features in Plone's REST API, I'd recommend contacting the authors of plone.restapi first.

Regarding your statement "The DELETE request allows users to delete single item as opposed to the whole document/folder.": this is incorrect. A folder is a single resource, as far as HTTP and Plone is considered. Issuing a DELETE /news/about-cats will delete the folder 'about-cats' and its children.

I'm looking forward to your response, and have an awesome day!

-Roel

Hi Roel,

Thank you very much for your feedback. I really appreciate it.

My document definitely needs to be restructured.

I would like to improve the REST API. However, I found it necessary to change from Zope to WebOb if ever I want to improve it. Maybe I need to shift the focus of this doc more into the change from Zope to WebOb rather than REST API improvement because it is a long and heavy task. Then I can get a drop of my idea on the REST API improvement.

I am looking at the REST API repository. I am also going to contact Ramon, (the responsible for the Rest API and the mentor for changing from Zope to WebOb.

Finally, please allow me to respond to this thread again in the next two days on my findings.

Thank you.

Improvements to the Plone REST API and integrating WebOb into the Zope stack are two different things with little overlap, as far as I can tell. Both are worth individual GSOC projects. REST API work could also include some work on the Zope Publisher and ZServer to support REST verbs, but the Request/Response object framework is not so important for REST.

WebOb integration for Zope was one of the topics we collected at: Summer of Code 2016

Thinking about the purpose of the WebOb proposal, I think it could help with a future transition to Pyramid and interoperability with WSGI. Anything else?

Absolutely. There is not much relationship between both topics.

-aj

The typical "REST verbs" form a subset of the WebDAV commands - and are as such already supported by Zope (in fact, they are completely transparent to "ZServer" and mostly transparent to "ZPublisher" and implemented by the WebDAV class).

Have you heard about repoze? If I understand correctly, it's a reimplementation of zope that uses WSGI. I think it's by the same people who wrote pyramid.

1 Like

Interesting.

I guess it's more worth it to set up an interface in order to compatible with Zope, Repoze and WebOb. This is just a prototype and should be considered as an add-on, not core development.

Reason Im talking about WebOb is because of this link
https://plone.org/events/summer-of-code/2016

Overall, the former proposal is unrealistic.

It's better if I create a prototype of deploying a small part of Plone under WebOb. This is, it considered to be an add-on feature of Plone.

My recommendation is that you stop any work related to Zope request vs WebOb migration since you are miles away from having the big picture for making such significant changes. Such work requires experiences and a very solid knowledge of all pieces.

-aj