Jim Fulton wrote:
[snip]
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.
Regards,
Martijn
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
