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

On Thu, Mar 09, 2006 at 04:09:15PM -0800, Mike Orr wrote:
-> On 3/9/06, Titus Brown <[email protected]> wrote:
-> > I might well be alone in this, and I don't want to seem like I'm
-> > kvetching without point, either.  I love Quixote, and you guys designed
-> > it, built it, released it, and are maintaining it.  I just think things
-> > may evolve in interesting and useful directions with a more bazaar
-> > style of development.
-> 
-> Actually, Titus, we're thinking along the same lines.  I thought I was
-> the only one.  I'm itching to modify Quixote and QPY this weekend to
-> be native WSGI, and adjust the existing servers to be compatible.  If
-> you want to collaborate and incorporate session2, let's do it.  It
-> doesn't have to be a "fork" per se, just an experimental "branch".
-> 
-> I don't think the MEMS Exchange has to be more bazaar-like or to
-> accept things they don't want in Quixote or QPY.  Their first
-> responsibility is to their internal applications and their paying
-> clients.  Many thanks to the MEMS Exchange for open-sourcing Quixote
-> with a BSD license.  But I have my own design ideas I want to try,
-> things along the TG/Paste lines.  We just need an independent
-> repository to tinker on.  Then David can decide later whether to
-> incorporate the changes into Quixote/QPY, or we can later fork for
-> real or turn it into some kind of Paste component.

Hi, Mike,

the last thing the Python world needs is another Web app framework ;).
Personally, I would rather see Quixote die as a publicly traded
framework than inflict yet another badly documented niche distribution
on the Python community.  It's time to *kill off* Web frameworks, not
*produce more*.

(Yeah, I purposely worded that strongly. ;)

I think MEMS Exchange will have to take a stand at one of these three
points:

	(a) disclaim interest in producing a Quixote 3.0;
	(b) proclaim willingness to open up development in some way,
		but retain it under the MEMS Exchange umbrella;
	(c) disclaim interest in (a) or (b) and continue onwards.

If (b), I'm happy to contribute some or all of the below on an
as-time-permits basis.

Were they to go the (a) route, I would be happy to provide a subversion
server, Trac site, mailing list, mail archive, and all the other
trappings of a community project.  I can provide full-access subversion
accounts, shell accounts, etc. easily enough.  (In any case, I don't
think these are real issues -- there's too many other options out
there!)

More importantly, I'd also be willing to commit to finishing that damn
tutorial I started (it got bogged down by the need to rewrite session
handling...), writing a functional test suite for the core code,
breaking out pieces of reusable code from the core, and helping organize
a more flexible plug-in system so that 3rd-party packages could be used
without accreting onto the core code.  I'd also like to work out a
roadmap-like structure to distinguish between *including* and
*supporting* the various features that you (Mike Orr) suggested in your 
original e-mail:

	http://mail.mems-exchange.org/durusmail/quixote-users/5401/

But I really, really, really, really, really, really don't want to start
a new project that diverges from the Quixote project.  FWIW, I'm
long-term committed to Quixote, and I think it would be a huge mistake
-- a waste of time in the long run -- to indulge in anything fork-like.
A name change, maybe -- Phoenix would be a pretty cool name ;).  But not
a fork.  Anything but a fork.

Sorry to dump all this on you all, but I guess it's been building for a
while...

cheers,
--titus