Kyle Burton on Fri, 27 Aug 1999 09:01:09 -0400 (EDT)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [Plug] Python vs. Zope


> Does anyone have any experience with Zope (zope.org)
> or Python (python.org) with creating interactive web
> content (especially database) with Apache?  Both of
> these are impressive looking examples of open source,
> but which is better?

I've only looked at these, I've never used them, and I'm no real expert
on them.  Having said that, I will tell you what I know (explaining this
will help me define my own limited knowledge of these things).

Python is a general purpose programming langugae.  It's object oriented,
and one difference [that I've seen] from most of the other languages that 
I've looked at/used (c,c++,perl,java), whitespace matters to it [python] -- 
this means that when you write code, the way you format it has meaning to 
the python compiler [interpreter].  It's an interpreted language (like 
basic,lisp,or perl).


Zope is an application server.  It uses python as it's language of choice for
writing the applications.  Application servers are generaly used to build
highly interactive web sites (and I think this is what Zope was created for).

They [application servers] were designed to provide more features and greater 
performance than using something like standard CGI.  They typicly offer 
persistient state information that is automaticly associated with a specific 
user [browser], so when you write code for an application, you automaticly 
have access to user specific data (this is typicly acheived [in a web context]
by using a session id stored in a cookie, and it's matched up with persistient 
data in the application server -- but the matching/saving of data is handled 
automaticly by the app server).

So that they can scale across multiple servers, the application servers must
replicate their information between each other.  This allows you to use load
balancing.  If a user's request comes in to machine A, and they modfiy thir
session data in some way, when the next request comes in, the data must be
available regardless if it comes in to machine A again, or B, or C, etc.


Standard CGI can do some of this using techniques like storing the data in
the file system (though this is much slower than keeping it in memory as
app servers typicly do), or storing it in a database (which would also be
slower).  But with CGI, you still incurr the fork&exec penalty.

mod_perl (actualy the Registry module) with apache can provide better 
performance, but it provides no data replication services (not even between
instances of the apache http daemon on the same machine).  So mod_perl will
get around the fork&exec issue, but doesn't provide the more advanced features
of an application sever.

App servers are almost always designed using object oritented technologies
(Java is widely used as the implementation language in the commercial app 
server market) to give you the ability to write distinct objects that 
encapsulate singular logicical operations (what these are are defined by 
what you'r application needs to do).  This is done with the idea that they 
can be used like building blocks, interoprate, and just be plugged, stacked, 
and put togeather however is needed for the application on a grand scale.

They're typicly a better technology for large applications than using 
something like a server side scripting system (ASP, JSP, ColdFusion, etc.).


Compare Python to:  Basic, Lisp, C, C++, Java, Perl, etc.
Compare Zope to:    Netscape Application Server, Oracle Application Server,
                    Sun Microsystem's Net Dynamics, IBM's WebSphere

k

------------------------------------------------------------------------------
The simplest answer is to act. 
    -- Anonymous (from a fortune cookie fortune)
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------


_______________________________________________
Plug maillist  -  Plug@lists.nothinbut.net
http://lists.nothinbut.net/mail/listinfo/plug