On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote:

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.

I suspect you are confusing, as the repoze folks seem to have, the publisher, with the way that the Zope 3 server set up code wires it up. When we originally set up zope.server at the dawn of Zope 3, we inadvertently created a gordian knot of interacting components. When we added WSGI and Twisted support, we just made this worse by adding additional threads.

The basic publisher framework is pretty straightforward. There is a generic publisher and a publication component that takes care of customizing the publisher for a particular application. The publication interface, zope.publisher.interfaces.IPublication, defines the available hooks. The recent addition of zope.publisher.paste makes selection of a custom publisher much simpler -- as well as supplying paste support. Unfortunately, I don't think anyone has paid attention to this. :(

If all you want is more control over how the publisher works, I think the current publisher simplified via the new paste support should meet your needs. It's possible some folks need more hooks, but then we should focus on evolving the publication API, zope.publisher.interfaces.IPublication.

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?

Yup. In fact, all I'm planning to do is to move most of the existing publisher code to a separate package sans interface declarations, xmlrpc, and a few other things that many applications don't need. I intend to keep the current publisher+publication framework. I don't expect to rewrite any code, other than tests, or change any semantics. In fact, I'd like migration from the leaner pubisher to the full publisher to be as easy as in import change.

I'd be interested in using such a publisher as the foundation for the publisher in Grok.

Why? (But read to the end before answering. :)

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.

Then why do it? (ditto)

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.

I encourage you to study zope.publisher.paste. I content that the publisher itself isn't that complicated.

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

REST support cannot be distinguished reliably

I don't know what you mean by REST support. Could you briefly explain?

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.

I don't really know what you are talking about. I'll make a few notes that may be responsive, or simply argumentative. :)

- I hate skins. They cause me only pain. They cause lots of subtle complexity. I acknowledge that they provide some benefits but I don't think the benefits are worth the cost. IMO, the problems that they solve can be solved in less magic ways. Note that skins are not intrinsic to the publisher. They were imposed on the publisher in the complicated request-factory dance.

- I think the current mechanisms for dealing with XML-RPC was a mistake. It's waaay too complicated. The whole request-factory dance contributed to the complexity of the publisher configuration.

- I fixed a bug in the publisher over the weekend that may have contributed to your REST woes (whatever those are:). I've been doing lots of ajax (sans xml :) lately. Following standard ExtJS practice, I've been making requests as form data and getting JSON responses. I wanted my requests to be JSON too and found that POST requests were swallowing non-form/non-multi-part bodies. Now in zope.publisher. 3.5.1, these bodies are left intact.

- To deal with AJAX requests, rather than changing the request setup logic to introduce a new request factory , I've localized the specialized behavior in descriptors (exposed as decorators). I use simple views that return pages that load JS applications. These JS applications make ajax calls to sub-urls of the original pages. In my view classes, I then have simple ajax methods that take and return Python data. Something like:

    def add(self, value):
        if not isinstance(value, int):
            return dict(error="The value must be an integer!")
        return self.do_add(value)

I'll be releasing this code with documentation in a week or two. I don't bring this up to plug my work, but merely to point out that there are simpler and. more importantly, more localized ways to approach protocols layered on HTTP.

Security proxies: this topic may not be directly publisher related,

It's not.

but maybe it is.

Nope. :)

Somewhere quite low in the request handling of Zope 3 a security proxy is introduced around the objects being traversed.

This is done by the default Zope 3 publication object, zope.app.publication.zopepublication.ZopePublication.

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.

There always has been, as I've mentioned many times. The same hook point allows use of Zope 3 without ZODB. These policies are provided by the publication object. It's a shame that the convoluted setup system made this so inaccessible.

My hope is that zope.publisher.paste makes it *much* easier to use a different publications and thus a different set of policies. (I plan to update zc.zope3recipes to provide an instance recipe pased on paste.)

I'm 99% sure that most or all of the simplicity to want has already been there for a long time or is there now with the simpler setup framework in zope.publisher.paste.

Note that my proposal wasn't to simplify the publisher. I think it already is pretty simple and I hope the recent zope.publisher.paste work exposes the simplicity by stripping off layers of overly complex setup. My proposal was simply to extract some core functionality in a way that greatly reduces dependencies. I don't expect this stripped down version to be of interest to most of the zope community. I do think it might be useful to people with much more limited needs. I didn't the proposal because I thought it would be of general interest, but to ask permission. I want to do this refactoring, to avoid a (yet another) fork of the publisher. I should have made this clearer.


Jim Fulton
Zope Corporation

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