[Web-SIG] Web Container Interface

[Ian Bicking]

On Jan 24, 2004, at 10:03 PM, Phillip J. Eby wrote:
[snip]
> I am, however, beginning to see the awkwardness of "container" and 
> "app".  I'm wondering if maybe "gateway" and "service" would be better 
> terms, and rename the whole thing the Python Web Service Gateway 
> Interface.  That is, the WSGI, perhaps to be pronounced "whisky".  :)

I like gateway.  Service is very vague -- maybe the gateway is 
providing an HTTP service.  There's all sorts of services.  But I'm 
coming up blank on an alternative.

[snipsnip]
>> Again, I'm not proposing we set out a standard that covers these, but 
>> that we leave room for implementations to extend the standard to 
>> cover these cases.
>
> Well, for Twisted, Zope, and PEAK at least, each framework has ways of 
> specifying interface metadata about an object, including adapters.  
> So, gateways provided by those frameworks would be free to try to 
> introspect a service for a fancier interface.

That's true, but I think the services should be able to query the 
gateway as well.  I part because the "inside" of the application, where 
you start to battle portability issues, is likely to occur in the 
services.

> For example, PEAK has a 'suggestParentComponent()' API that can be 
> used to sniff an object for PEAK component-ness (using PyProtocols), 
> and then tell it what context it's being used in.  Zope 3 has 
> getAdapter(), and Twisted has ISomething(ob).

Well, if we're going that way, then we don't need this interface 
specification at all.  I don't know -- it's all overlapped at that 
point.

If we're relying on adapters, we could just use adapters only.  The 
only specification is that you give a service object to the gateway, 
and let the gateway figure out the rest.  I don't know, once you bring 
those mechanisms into it it confuses everything.

> None of these mechanisms require anything special in the WSGI spec to 
> support them.  And even if you don't have those, there's still good 
> old fashioned 'hasattr'.  You'll notice that I keep emphasizing the 
> gateway inspecting and invoking the service, *not* the other way 
> around.  There should not *be* anything different from one gateway to 
> the next, if at all possible, since that runs counter to the whole 
> point of the exercise, which is allowing the same service to run in 
> different gateways, *especially* ones it wasn't written for.  That's 
> why I want the spec to be mind-numbingly precise about what is and 
> isn't required, and don't want to throw a vague parameter into it that 
> has no meaning at all, existing solely to introduce *differences*, 
> which are the mortal enemy of the goal of sameness.  :)

Gateways aren't all the same.  They just aren't.  Gateways can't and 
won't be uniform.  They can't attempt to be uniform except by taking on 
an every-expanding set of responsibilities.

[snipping a bunch]
>> Portable applications in Python typically require some special cases 
>> as issues arise -- it's better to enable developers than to enforce 
>> agnosticism.
>
> Even so, I think it's better to have that glue controlled by the 
> application's integrator, rather than buried inside.  If the service 
> has options X and Y, let the integrator choose what behavior is 
> appropriate for the gateway they're installing it in.  Otherwise, 
> you're forcing the app developer to know about all possible gateways, 
> which again runs counter to the point.
>
> I think I see now why we seem slightly at odds in this discussion.  
> Your example suggests that you are thinking of "app" as "what I write 
> to do useful work", and that you will write apps that directly export 
> a service for use by a gateway.  While it's definitely possible to do 
> this, you will more likely use a service wrapper that's pre-defined by 
> your app framework such as Zope or Webware.  This is a way to take a 
> Zope or Webware application and run it in a different server 
> environment, not to make the application itself portable between Zope 
> and Webware.

No, I'm thinking of the application/service as a framework as well.  
But I just don't see how a framework can fit into such a minimal 
interface and still be portable.  For instance, how do I implement 
sessions?  I don't see a portable way to do that in the service given 
this interface.  I don't even see an unportable way to do it.  Unless 
you propose that the code to add the service to the gateway should 
include all sorts of options to cover all the particular details... but 
I don't see how that will help any.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org