[Web-SIG] Re: Just lost another one to Rails

[Ryan Tomayko]

On Apr 15, 2005, at 5:30 PM, Paul Boddie wrote:
> On Friday 15 April 2005 22:31, Blake Winton wrote:
>>> I'd love to find out that I'm wrong, although I guess I would
>>> find the WSGI idioms around accessing request headers/form-encoded
>>> data and collecting response information a bit cumbersome compared
>>> to the APIs provided by Webstack, Quixote, Webware, CherryPy, etc.
>>
>> Is there any commonality between those APIs?
>
> Perhaps. WebStack originally took some inspiration from Webware and 
> the Java
> Servlet API, but I think that the "vocabulary" is pretty standard, so 
> it
> isn't necessarily that difficult to map WebStack API methods to 
> framework
> methods. Quixote and CherryPy may have similar abstractions, but 
> unlike most
> of the frameworks supported by WebStack, these frameworks impose 
> various
> constraints (object publishing and template-orientation) that 
> seemingly make
> it impractical to support them in an API at WebStack's level.

Right - and that's fine. I'd rather see the frameworks follow a common 
set of "interfaces" for request/response/session/cookie/form objects 
then to have Webstack wrap the existing frameworks anyway.

Object publishing, template orientation, form toolkits, template 
systems, etc. is where I see each framework distinguishing itself from 
the next. The basic set of objects that wrap the HTTP lifecycle are 
very similar and I don't think anyone is choosing a framework based on 
these components.

You could split most Python based web frameworks into a couple layers I 
guess:

  1. Gateway Interface and Middleware (WSGI)
  2. HTTP Lifecycle Objects and APIs
  3. Routing, Object Publishing, Servlet Mapping,
     Validation, Form Handling, etc.
  4. Templating

Layer #2 seems like another obvious place, like WSGI, where 
compatibility could be beneficial and not overly stifling to the 
individual framework. I think layer #3 is where things start getting 
really messy because the techniques vary from framework to framework.

I realize I'm simplifying a bit - some pieces of functionality, like 
session management, blur between multiple layers and might be 
challenging to do well with additional restriction.

Ryan