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
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
