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

[Lucid Drake]

Less talk, more action.

At the risk of putting myself out there as all talk and no action, I 
think it would be useful for those on this list that have a strong idea 
about what should be added to the Python standard library, to post 
something that people can play around with.

I am by no means an expert in the world of web programming, but I am 
learning, and I do feel the need to have a better set of standard tools 
in Python for developing web applications. I just don't have the 
knowledge or expertise to develop something myself.

But what I've noticed is that there are spurts of activity on this 
list, but no progress. Perhaps if someone actually coded something and 
allowed others to play with it, some progress would be made.

I recall hearing the argument that whatever is developed shouldn't 
break current frameworks, or force them into a model they don't want to 
use. My question is, why would a new module break or force anything? 
Won't the original modules still exist?

In addition, even if the new proposed way of doing things breaks a 
framework, how long would it REALLY take for the framework to 
accommodate the changes?

All this talk is going no where, what ever happened to experimentation? 
Create something, test it, use it, stress it, and learn by doing. Less 
abstract design and more progress through action please.

Am I right? Wrong? Not seeing the entire picture? Please, more 
experienced developers/politicians chime in.

Thanks,
--Sean

On Mar 18, 2004, at 2:56 AM, Paul Boddie wrote:

> 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
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/lucid%40escex.com
>