[Web-SIG] AMK's "Web applications (again)"

[Phillip J. Eby]

At 02:29 PM 8/3/04 +0200, Paul Boddie wrote:
>Phillip J. Eby [mailto:pje at telecommunity.com] wrote:
> >
>
>[Roger Espinosa]
>
> > > But: all these frameworks *deploy* in a standard fashion, and (I
>think)
> > > the frameworks can happily co-exist in the same deployment.
> > > That's the part that I find lacking in Python: all the apps have
>their
> > > own deployment strategies, and often seem to relish in Python's ease
>of
> > > setting up micro-servers.
> >
> > This is what the WSGI proposal is meant to tackle.  I'm currently
>still
> > putting off a rewrite of the proposal to address the issues raised by
> > folks on this list, and to extend it slightly to better support
> > architectures that want to either be asynchronous or to pipeline
>request
> > preprocessors or response postprocessors.
>
>Originally, when I looked at the proposal, I interpreted it as a means
>to run different server frameworks on top of a common "transport"
>container - a kind of multiplexing arrangement. However, looking at the
>text now, what the WSGI proposal [1] also seems to advocate (looking at
>certain examples [2] for clarification) is the ability of applications
>to use existing framework APIs but then to have those applications
>deployed on other frameworks - to a Webware application, for example,
>all frameworks look like Webware.

Right, that's not a bad way of putting it.  When I redo the PEP for WSGI, 
the terminology will hopefully be clearer.  In fact, "WSGI" now stands for 
"Web Server Gateway Interface", so it might be more correct to say that "a 
Webware application could run on any web server that supports WSGI."


>But then, looking deeper at the proposal, I wonder how the WSGI-defined
>concepts fit in with those framework APIs. If input, output, errors and
>environ have standardised semantics, it occurs to me that the semantics
>of the framework-specific objects used by the applications must be
>translated to the WSGI semantics as defined in the proposal.

Absolutely.  However, those are by-and-large the semantics of HTTP and CGI, 
which form the basis for most existing web servers and gateway 
protocols.  Any framework that supports being run under CGI (or FastCGI, or 
any of the FastCGI clones) is relatively simple to adapt to WSGI.


>Anyway, I'm curious as to how the described interface relates to the
>WebStack API in purpose and functionality. The principal objective of
>WebStack is to provide applications with a common API across different
>underlying server frameworks - to WebStack applications, all frameworks
>appear the same (they provide the WebStack API). Perhaps there is some
>overlap between the semantic translation part of WSGI and the objects
>provided by WebStack. Moreover, it might also be interesting to contrast
>the concept of a WebStack framework adapter with parts of the WSGI
>proposal.

I took a brief look at WebStack yesterday; my impression is that under 
WSGI, your framework adapters would be unnecessary, because you'd just have 
one for WSGI.  From WSGI's point of view, WebStack is just another Python 
web framework.


>On the subject of deployment, however, the Java-style standardised
>deployment with things like .war files and descriptors doesn't
>necessarily deliver everything that the hype would suggest, as anyone
>who has had to work with more than one application server would know.

Well, WSGI isn't trying to standardize to *that* level as yet.  :)  That 
would be a different PEP at some later stage after there's some field 
experience with the interface.


>Moreover, the more Web applications appear like normal Python packages
>and programs, the easier they are likely to be to deploy, especially if
>the means of deployment doesn't involve uploading some archive file to
>some Web application and clicking a "restart" button - something that
>turned many people away from Zope, I'd wager. In certain circumstances,
>the lightweight "micro-servers" really do have their advantages...

Well, all of the frameworks are free to "innovate" as much as they like in 
this respect.  Different systems have different user 
audiences.  Personally, I wouldn't mind someday seeing a standardized .zip 
format for deploying applications to a web server... as long as you can 
build it with the distutils!