Kevin Dangoor wrote:
On 2/10/06, Mike Orr <[EMAIL PROTECTED]> wrote:
Not sure if this can be done quite as soon as the sprint, but I'd like
to see some more convergence between TurboGears and Paste. TG
piggybacks on CherryPy's configuration system, and Paste has a
different system. People recently brought up RhubarbTart, and
CherryPy's filters vs Paste's middleware. It looks like
interoperability between projects is the best for the long term, the
same way that template plugins were seen as a minor good but turned
out to have significant unexpected benefits in addition (TurboStan,
etc). I don't know whether CherryPy's configuration system is better
or worse than Paste's, or filters are better/worse than middleware,
but it's a shame to have two incompatible pairs of systems, and
perpetuating them just makes it harder to interoperate in the long
run.
This is the kind of big-ticket item that I'd like to talk about at the
Sprint... to at least knock around some ideas, if nothing else. It's
also worth noting the presence of CherryPaste and additional new work
that has gone on with CP's WSGI support. There are now a number of
potential ways to get access to WSGI middleware and other
applications, and those are worth considering.
I should be around for the sprints, but I haven't decided what to do
yet. I'd be interested in working on combining TG and WSGI a bit more
intimately, especially if there are other people interested in working
on that. I think a good goal for a sprint is not necessarily just the
code written at the sprint, but helping to introduce people to new
things and make people comfortable with code bases that might otherwise
seem intimidating.
I'd also be particularly interested in a WSGI-level caching middleware.
This would be based primarily on HTTP style cache controls, almost
like a caching proxy, except in WSGI and in-process, so there's a lot of
extra controls and interfaces you can put on it. I know there's several
other people outside of TG that would also be interested in this on the
WSGI level. The HTTP level is also where you can insulate Kid's
performance problems -- any caching before the template won't have
anywhere near as much effect as caching the rendered page.
It might be nice to look into merging some of the changes I made in the
paste-error-reporting branch into Kid. But to use that in TurboGears
requires using Paste's exception formatter. But if you want to move to
paste.evalexception (which you should want to do), then you'd be doing
that anyway. That also gives you access to view local variables.
I also have a stealth SQLObject project that would be fun for a sprint
(green field), but I haven't really committed to that project myself
yet, and it wouldn't really help TG get to a stable base any faster
(unless the project was wildly successful). There's also lots of
SQLObject stuff that is more maintenance-related, which would certainly
be useful to do -- things like straightening out the cache situation,
transactions, eliminating the naming conventions, polishing
sqlobject-admin's rough edges.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
