Re: Quixote 3

On Mar 7, 2006, at 12:29 AM, Mike Orr wrote:

> TG has implemented
> pluggable templates (TurboCheetah, TurboStan, etc), and is
> experimenting with replacing CherryPy with a minimal traversal library
> (RhubarbTart) linked to Paste, and with replacing SQLObject with
> SQLAlchemy.  My own project is having problems with SQLite
> performance, and I may have to substitute Durus or put the 30 MB
> database into memory.

Do you mean you consider switching to Durus from SQLite due to a 
performance issue with this particular project?  SQLite is already a 
lean and mean db, and with such a small amount of data I would 
certainly be very curious what specific issues you are having that 
would make you consider such a switch... (and that could be a big 
separate discussion, so may be over on the durus list?).

W.r.t your comments on the framework's "db component", working with QP 
I realize that the interface  between QP and the special data classes 
it expects (i.e. user and session) is really quite minimal, and I'd say 
very feasibly replaceable by your ORM of choice, or any other OO layer 
of course. (There is of course a lot of interaction within the classes 
themselves, but with QP "on the outside" of them there is surprisingly 
little). I mention this because I think this openness is a point in 
QP's favour (I'd hazard a guess that replacing the ORM in django or TG 
will be a whole other story), and because it makes me think that the 
conceptual difference between Quixote and QP is as big as one (me;) 
might expect. Of course QP has numerous improvements, such as QPY, but 
Quixote would anyway have to improve in the same ways...

So, you talk about Quixote 3 -- I think that would be another name for 
QP made slightly more open, in particular giving QP the option to run 
without a db, and formalizing the interaction it would require from the 
db when it is used with one. I think that would be an interesting route 
down which to merge the 2 frameworks.

mario