[Web-SIG] Shameless self promotion, and serious question.

[Paul Boddie]

Ian Bicking [mailto:ianb at colorstudy.com] wrote:
> 
> Paul Boddie wrote:
> > More self-promotion, but what do you think of the WebStack stuff I
> > announced on PyPI?
> 
> It kind of opens all sorts of questions.  For instance, it's not 
> unreasonable that Webware could run under mod_python or Twisted (I think
> a mod_python version existed a long time ago, and I experimented with 
> running it under Twisted a while ago as well).  (And Quixote already 
> does this in a less experimental fashion)

To me, running Webware on top of another framework seems only to have
deployment benefits, although one could easily say the same about WebStack.
However, Webware also ties the developer to a way of working which carries a
lot of semantic baggage - the servlet model, threading, and so on.

> So, Quixote, or a more developed Webware, or a bunch of other 
> frameworks, could each be a kind of compatibility layer of their own. 
> Well, they *could*, but I don't think it's that easy.  But why not?  I'm
> not up to figuring out quite why right now -- but I think it has to do 
> with fuzzy layers.

Yes, one could argue that hiding the special parts of frameworks or
correcting the behaviour of such frameworks is the wrong solution to
whichever problem one is trying to solve.

> It seems natural that a framework could support one of several 
> underlying layers (e.g., Apache and Twisted).  But the layers aren't 
> very firm (what's "underlying"?).  Can Quixote work under Webware and 
> vice versa?  Or something heavier, like Zope?  And what does "work" 
> mean, anyway?  Perhaps that a URL space is segmented off, delegated to a
> subframework.  Or by extension, ala Apache?  What about the frameworks 
> intermediate work getting to that subspace, like if Zope authenticated a
> person at a higher level in the URL?

Actually, the issue here seems to be how deep your frameworks are. Most
Python frameworks seem to aspire to "deepness", covering everything from
socket communication right up to session management and application
semantics. What I'd rather see is a collection of layered frameworks and
components which each do their bit of the job. WebStack mostly sits above
the communications layer, using the existing frameworks for that layer and
reusing other parts of those frameworks for higher level features that
should arguably exist elsewhere.

Above WebStack should be components which interpret URLs, control access to
resources, and provide the application-level services. A counterexample of
such an architecture is "Zope plus Products": by the time a Product instance
gets hold of request information, a lot of the decisions about where that
Product instance resides in the URL space have already been taken, but
that's arguably the whole nature of Zope and the way it works and is just
one reason why some people don't really get on with Zope.

> I don't know... I don't think it's necessarily *that* hard.  But we have
> to think recursively somewhere in here, instead of layers -- we can only
> build on lower-level layers for a while, at some point peers have to 
> work together in a friendly way.  In this case that would mean running 
> Webware ontop of WebStack ontop of Twisted, or seemingly silly things 
> like that.  But it's not really that silly, because I suspect it would 
> be fairly useful.

I'm not advocating a Web frameworks equivalent to User Mode Linux. ;-)

> But I'm not exactly sure how reasonable it is -- maybe it would be 
> better to decouple frameworks and separate layers so that this doesn't 
> all have to be so vague, and so we can feel more confident in how things
> will work together.

I'd certainly advocate such an approach instead, however.

Paul