On 25 Oct 2005, at 12:46, Mike Orr wrote:


> The question for Quixote is, what does it want to be in this new era?
> One option is to cede the beginners' market to TurboGears, and my
> hunch is that's the best.  Aquarium's author (JJ Behrens) has
> expressed willingness to do this if TG (or another) becomes the
> frontrunner, and wishes such a framework existed when he wrote
> Aquarium.  We can position Quixote as "a toolkit for advanced users
> who want more freedom than TurboGears gives them".  That would argue
> against investing in elaborate tools to create a Quixote "project"
> directory: that work should go into supporting the emerging beginners'
> framework instead.   Which will probably be CherryPy-based, since both
> TG and Subway use CherryPy, and CherryPy has the best WSGI interface
> to Paste.
>

For me, the lack of scope of Quixote was one of the big wins. It
didn't try to do everything, and I could ignore the bits I didn't
like or didn't need. So here at work (BBC Radio & Music
Interactive),  I'm building internal apps using Quixote as a URL-
dispatch layer, with Cheetah as a templating layer, all held together
by my own glue layers. I'm not using PTL or the forms module. If I
wanted to use TurboGears or Django or Rails I'd have to follow their
proscriptions.

This isn't a fundamentally bad thing: the frameworks are really great
if you're developing apps which fit snugly within their creator's
philosophy of app development (the Rails guys are very open about
this, and it makes a lot of sense). But, once you step out of that
then you have to face dealing with code which is actively hiding the
stuff you want or need because its job is to shield that from you and
steer you in the direction the framework thinks is correct.

What I'm doing at work is creating a series of small apps which share
a large core, something which is essentially something conceptually
similar to a Rails or Django: I need something to help me build my
suite of highly inter-related apps.

Because of its smallness, and focus, Quixote can fit into that in a
way that TurboGears or Rails never could.

I suspect that there'll be an increasing number of people who find
themselves developing systems which share the same philosophical
space as the current crop of frameworks, except that they'll be more
and more specialised, allowing their creators to make slew of highly
specialised apps on top of them. For example, our internal
authentication infrastructure is complex and every app needs to use
it, as is our publishing situation, so my almost-framework will make
those available simply and transparently to every app I create.

I don't think that Quixote has anything to worry about as long as it
stays focussed on its core competency and keeps its 'gets-out-of-your-
way' philosophy central. That could well mean trying to shed the need
to directly provide app server code, maybe WSGI all the way. It could
also mean making it easy to mess where messing is needed (for
example, my desire to mess with HTTPRequest without messing around
beyond the Publisher)

Hope that makes some kind of sense.

Matt

--
   Matt Patterson | Design & Code
    | http://www.emdash.co.uk/
    | http://www.reprocessed.org/