[ZDP] ZPublisher

[Pavlos Christoforou]

Hello Tom -

On Sat, 8 May 1999, Tom Deprez wrote:
> 
> One question dough. So ZPublisher is protocol independent.... I thought
> several modules were written of ZPublisher....
> PCGI, Fast CGI, ZopeHTTPServer, ....... Or, can we assume this layering,
> ZPublisher below written modules :

ZPublisher *should* be protocol independent but initially it was build
with http in mind and until now large parts of it betray their decent.

You can think of ZPublisher as the mechanism resposible for converting a
string of type:

"/a/b/c"

into a retrieval of subobject c from subobject b from root object a. Of
course it does much more but that's the basic principle. It will for
instance try different methods of accesing the subobjects, pass argument
data to the relevant methods, take care of cookies, provide authentication
mechanisms, decide which methods are publishable or not, etc.

IMHO the most amazing technology in Zope is not the ZPublisher but the
ZODB. The Z object database is the heart of the whole thing. However it is
so well designed that it is totally transparent to the end user, and
therefore nobody ever talks about it.

So on one end we have a container full of python objects organised in a
hierarchy, that have publishable methods. The desire is to provide network
access to these objects and their methods so we need a protocol that is
flexible enough to pass around a request string and a number of arguments.
The HTTP protocal provides enough flexibility and it is a widespread
protocol. ZPublisher sits in between your web server and your Zdatabase
and converts the URLs of incoming HTTP Requests to object traversals,
calls the relevant methods and returns the result. You do not have to
include a tag of HTML if you so wish and indeed you can use Zpublisher and
a web server to build a complete distributed objects application.

Now the problem is how to pass the URL,cookies and parameters to the
ZPublisher so it can do its job, and thats where CGI comes in. A cgi
enabled web server will pass all the relevant information (and even more)
to the requested cgi script, which is exactly what Zpublisher requires.
Therefore you can publish objects with any web server that supports cgi.
This is of course inefficient as every request has to restart python, load
the relevant libraries, read and execute the code and provide the
responce. Things like PCGI essentially start a python process and keep it
alive so that new requests can be served very fast, but are *not* needed
for ZPublishing of objects. For even higher performance you could include
a ZPublisher handler directly into the web server and this
is what happens with Medusa and the  ZopeHTTPServer. They are both written
in python so one can 'intercept' HTTP requests and redirect them to the
ZPublisher. Medusa (and the accompanied asyncore libraries) is one of the
finest examples of python code in the community and provides a very
modular approach to the whole process of client server applications. Thus
one can write his own handlers that essentially tell medusa how to process
incoming requests, http, ftp, webdav or whatever the future might bring.

> 
> So,  if you don't use Medusa or the ZopeHTTPServer, you first use a writen
> pcgi, f cgi module :
> 
> e.g. HTTP req. -> Apache -> pcgi -> ZPublisher -> ....

No

HTTP req. -> Apache -> ZPublisher -> (python object hierarchy in or out of
a Zodb)


> If you use ZopeHTTPServer or Medusa : HTTP req --> ZopeHTTPServer or
> edusa  --> ZPublisher -->...

Same as above

For increased performance with existing webservers:

 HTTP req. -> Apache -> pcgi -> ZPublisher -> ....



> Medusa can even handle FTP requests :
> 
> So, FTP req --> Medusa --> ZPublisher -->

Medusa can handle any 'chat' like protocal. ie a protocol where the client
sends a text line request and the server performs some action. You could
use SMTP and you could publish python objects over email!

> 
> second q'n : why can only Medusa and ZopeHTTPServer handle direct HTTP
> requests, without using a pcgi, ... module

See above

> 
> Regards, Tom.
> 

Pavlos