Jim Fulton wrote:
Thoughts? Objections?

A simpler publisher has been on my wish-list for a long time now.

I'm a bit worried though that a publisher born from the current Zope 3 publisher with the goal to build up enough support for the Zope 3 publisher to make use of the code will not in fact be simpler. The current Zope 3 publisher supports quite a few pluggability points (though not necessarily always in the most convenient places), and has a lot of interacting components, which makes it rather hard to comprehend sometimes.

You seem to be confident you can create this simplicity while retaining enough pluggability to build the Zope 3 publisher back up on it, though, correct?

I'd be interested in using such a publisher as the foundation for the publisher in Grok. Of course Grok does currently use the current Zope 3 publisher in Zope 3, and uses quite a bit of functionality in it (XML-RPC, skinning, and some hackery to build up the REST support). Getting away from the current publisher won't be trivial. We couldn't make do with just the new publisher, but perhaps the new publisher + extensions will be simpler to comprehend still than the old publisher.

Note a few issues I had with the current publisher that might be resolved in a new one:

REST support cannot be distinguished reliably with a header (like I believe XML-RPC can). It needs to work in a proper browser. This means that REST support (low-level handlers for GET, POST, PUT, etc) needs to be mixed in an interesting way with the browser publisher. For PUT and DELETE this is not a problem, as the browser normally doesn't issue them. With POST and GET, the only distinction you can make from normal browser behavior is actually what URL is being used in the first place, and thus what view you're trying to get. In Grok's REST support I used a different skin to indicate this different kind of view. This required some hackery to support. It'd be nice if there were a cleaner way to pass GET and POST requests into separate handlers based on, say, the skin you're in. Perhaps Stephan Richter's rest package can do this; I haven't examined it yet.

Security proxies: this topic may not be directly publisher related, but maybe it is. Somewhere quite low in the request handling of Zope 3 a security proxy is introduced around the objects being traversed. Grok doesn't want security proxies, so rips them off again in a custom publisher. It'd be nice if there were a hook point that would enable us not introducing this proxy in the first place.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to