[Web-SIG] Re: Regarding the WSGI draft

[Phillip J. Eby]

At 09:50 PM 8/27/04 +0100, Paul Moore wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
>
> > First, users can experiment with other frameworks, especially if those
> > frameworks are lightweight.  This builds competitive pressure in the
> > direction of lightweight, easy-to-integrate frameworks.  So framework
> > developers begin to break their monolithic approaches down into smaller
> > pieces that operate on segments of WSGI.  For example, a session service
> > that you pass the incoming 'environ' and outgoing 'headers' to, in order
> > for it to read and set cookies.  (Notice that this *isn't* a WSGI-defined
> > or standardized service, just a service implemented *in terms of* WSGI.)
>
>I think this starts to address the question I raised in my previous
>posting, about "run anywhere" applications. If an application is
>written to use WSGI-compliant services, it could run on any
>WSGI-compliant server.
>
>But doesn't this raise a complementary issue? With 10 applications
>running, I have one server. But I also have 5 session handling
>services, 8 authentication services, 3 error handling services, etc,
>etc. Maybe that's where the pressure for "best of breed" services
>comes from.
>
>Small steps, I guess...

Right.  Journey of a thousand miles, single step, that sort of 
thing.  :)  Anyway, once you have 5, 8, 3, etc. things that are focused on 
specific areas, you have an opportunity for *focused* discussion on that 
area, and a chance of making some progress on a standard.  Right now, WSGI 
is focused intently on HTTP, because that's the *only* thing everybody's 
definitely got in common.

When WSGI is also "common", then it's easy to look at other layers, because 
the server differences are factored out.  So, we can pull out another 
layer, making the *next* layer up come into sharper focus, and so on.

And, as you say, the duplication *will* provide a new kind of market 
pressure, to reduce duplication and consolidate the choices.  The overall 
process is somewhat organic, I think, but it has to be started in a way 
that will take advantage of the forces currently in play (e.g. developer 
interest, existing investments, etc.) rather than working against them.