fuzzylollipop wrote: > there are lots of things you can't do or can't do easily or can't do at > efficiently in Apache using python as cgi or as anyone would more > likely assume mod_python. anything that requires any shared state or > shared resources in Apache is next to impossible. Doing similar things > in an app server or network application framework like twisted is > trivial.
What one really should be identifying here is that different tools are better for different jobs. Apache is a web server, and it isn't necessarily practical or sensible to try and shoe horn it into service as a full blown application server by and in itself. At the same time though, I would suggest that something like Twisted is in itself not always the best solution either, ie., to take an application server, and try and bolt on to it a web server. Yes Twisted can perform as a web server, but when compared to the functionality and configurability that Apache provides as a web server, it is always going to be a lessor cousin in that role. If you do not need the full power that Apache can provide and can live with the lessor abilities inherent from running the web server as a component within the application server, then great, but this isn't necessarily going to suit everyone either. Thus one is still faced with the question of whether you should embed the application in the web server, or wrap a web server around the application. Unfortunately from what I have seen, often the decision is made based on the narrow focus of expertise of the developers involved. A web developer will be dismissive of the application developer and vice versus. Each will say that it is trivial if done in the system which embodies their area of expertise, although usually that is said without them really knowing how they will achieve the part they don't know too much about. The strongest personalities thus will win as to how the system is built. The alternative is to accept that both Apache and application frameworks such as Twisted are each good in their own space and use both, bridging between the two as necessary. This could be done using simple protocols like XML-RPC or more sophisticated messaging system protocols where persistent connections can exist between the Apache child processes and the backend application server thus avoiding the creation of socket connections on every request. The use of messaging systems also means that presence information can extend into the realm of the web server and it can be easier to deal with failure or unavailability of components of the backed system. Keeping a split like this means you also have the added benefit that you don't end up with application server code which is somehow inherently dependent on or knowing that it is being used purely within the context of a particular web server. You don't end up with application server code being tied to the use of a specific means of rendering web pages. With this sort of split it doesn't matter whether you use CGI, mod_python, mod_perl or PHP for web page generation. Provided that the interfaces between the two are well defined, you can change the application server code structure as much as you like and the web page generation code doesn't need to change. The opposite also applies in as much as changes to the web page generation code shouldn't affect the application server code. Overall I would have to say that you are both right and wrong. Where the state is served purely by the use of the database, there is nothing wrong with Apache/mod_python in itself being used. Where the state also embodies the need to have active agents which operate on that data, possibly independent of web requests, then a back end application server which embeds the core functionality of the application would be better. In doing that though, it doesn't mean that Apache has to be discarded as the web server, and a web server embeded in the application server be adopted. Depending on the requirements, you will get a more flexible, more easily maintained system if a combination of the two technologies is used. Anyway, that statisifies my daily need for a good rant. ;-) Graham -- http://mail.python.org/mailman/listinfo/python-list
