Re: Quixote, WSGI, next-gen hypishness, etc

Titus Brown wrote:
> I, personally, find that Quixote+session2 does 100% of what I need it to
> do (perhaps modulo an ORM).  With just this package, I can write
> PostgreSQL-backed Web sites; publish/traverse object hierarchies; and
> create essentially any site I need.
> 
> Were I to want to mix and match functionality with WSGI, I would
> probably look for a few specific items -- caching, gzip, and URL
> mounters -- to tack on.  Commentary-style functionality is about as
> complex as I think I'd ever want to get.  It's *great* to know that I
> can do this with WSGI middleware.  It's also very nice to know that
> should I ever abandon SCGI, I don't need to do anything at all to my
> application: I just need to find a new WSGI server.
> 
> But *that's it*.  Nothing more.  Nada.  Zip.  Zilch.  I have no other
> needs popping up on my radar screen.

Switching out pieces is not something you do everytime, or a choice you 
consider constantly.  It's about splitting up development.  session2 
isn't in Quixote.  It has a different set of developers than Quixote 
has.  It has a different release cycle.  It has a different level of 
stability, a different set of users.

The fact that you want Quixote development to open up says to me -- with 
my WSGI-tinted glasses on -- that you want this kind of componentized 
system, because with that kind of system you don't *need* Quixote 
development to open up.

The normal way of building extensions to frameworks leads to a very 
small set of users.  If you build an extension to Quixote, you have the 
potential of only a fraction of Quixote users, which is a fraction of 
python web programmers.  Maybe if Quixote was a big framework that would 
work out okay -- Zope extensions do alright, for instance.  But Quixote 
isn't a framework with lots and lots of users, and never will be.  So if 
you want to build extensions you either have to (a) get everyone using 
them (i.e., get them included in Quixote), (b) be happy supporting a 
couple people, or (c) just do it private to your application.  And 
users, when they have novel needs, have to (a) write their own 
extensions, (b) use an extension that may or may not be supported, or 
(c) do without.

WSGI components answer these problems in a couple ways.  First, your 
extension isn't specialized to a particular framework, so you aren't 
getting geometrically smaller numbers of users with every extension. 
You don't need to push the pieces into Quixote, and so no one has to 
deal with the coordination overhead.  And users can feel a little more 
confident about the viability of the extensions they use, because at 
least they can switch if that turns out to be necessary.  They might not 
switch pieces often, but both knowledge that you can switch, and the 
ability to switch occasionally, are really useful.

> And, more to the point, I don't think I'm atypical.
> 
> I want a bundled package.  I want it simple, downloadable, installable,
> and straightforward.  I don't want lots of configuration options.  I
> don't need a choice between 5 different flavors of can openers, to mix
> metaphors.
> 
> Paste leaves me out in the cold.  It's too complicated to explain to
> most Python people, much less my mother (a smart woman).  I don't want
> all that configurability.  And I'd be willing to bet that 90% or more of
> Python Web programmers don't care much about that stuff, either.

Your mother shouldn't be using Paste.  You should be using Paste to 
present that combined thing you want -- assuming the thing you want 
doesn't exist, which is what *you've* said.  You want to hardcode a 
session2+Quixote system?

def make_titus_quixote_app(conf):
     app = quixote.make_quixote_app(conf)
     app = session2.wsgi_middleware(app, conf)
     return app

That's how you put pieces together; it's not complex.  I agree, you 
shouldn't expose every component, or encourage people to 
pick-and-choose.  *Someone* needs to pick and choose, and then provide a 
cohesive choice to other people, and probably a stable interface that 
wraps those choices.  To be reasonable, you have to acknowledge that the 
set of pieces will also change over time, people will want their own 
pieces or will want to replace yours.  This doesn't happen rapidly, and 
doesn't happen for every application, but that very tension is what 
*you* are feeling towards Quixote as it stands now.

Some pieces you may never switch out again.  That's okay too in this 
model.  And in the componentized model that actually works, because no 
one says that you have to switch out a piece you are happy with to get 
access to some othe piece.  And because these are isolated, you can 
test, stabalize, and release that one piece and then forget about it; 
it's not a liability of potential combinations that can extend or 
complicate each other.

-- 
Ian Bicking  /  [email protected]  /  http://blog.ianbicking.org