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

[Paul Boddie]

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.

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. Otherwise,
it appears that these semantics get exposed to the applications
themselves, making them non-standard within the context of the framework
API they are using.

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.

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.
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...

Paul

[1] http://mail.python.org/pipermail/web-sig/2003-December/000394.html
[2] http://mail.python.org/pipermail/web-sig/2003-December/000417.html