[Twisted-web] /freeform_post!!random causes exceptions

Andrea Arcangeli andrea at cpushare.com
Mon Jan 10 10:03:40 MST 2005


On Mon, Jan 10, 2005 at 03:52:49PM +0000, Valentino Volonghi wrote:
> On Mon, 10 Jan 2005 06:41:46 -0800, Ed Suominen <general at eepatents.com> wrote:
> >I would be interested, too.
> > 
> > Personally, I don't see the big deal about twisted dependency for Nevow 
> > stuff. To me, it's like saying humans are dependent on water.
> 
> It's probably time to start working on a sort of Nevow-extras to
> provide additional components/features that wouldn't fit well in Nevow
> (maybe because of dependencies).
> 
> 
> Because I also think that a good addition would be the sessionPersist module in Quotient and a TransactionalPage for Atop.
> 
> A checker against postgresql or something like that for async auth and such.
> 
> What are your opinions?

In terms of size, Nevow seems still pretty small (at least if compared
to twisted etc.. ;). So perpahps rather than separating it from Nevow,
we could simply create a submodule that is ok to depend on twisted (then
of course you won't be allowed to import it unless you're using
twisted). The email tracker is just an example of that kind of code that
is twisted dependent but that I believe everybody wants to use in
production (and in turn it would be inefficient having to rewrite or
cut-and-paste at best). OTOH I believe the exception mail tracker is
small enough that even if it gets merged in nevow.appserver (or a more
separate module like nevow.extras) that might be ok (even with local
imports since the exception handler it's not performance critical). I
don't know about the postgres and the other bits you mention (so far I
tried pgasync but it's not working correctly and its interface is
inefficient since it requires duplicating lots of code so at the very
least that needs fixing, while psycopg2 rocks).

Another misconception of pgasync is that it's not true a connection is
not expensive. If using ssl on a remote box connection handshake is very
expensive both for cpu and RTT delays, infact it may be more expensive
than the query itself (especially if run through the internet with bad
rtt). So pooling the connections is generally a good thing (even with
pgasync where doing it locally doesn't require clone() and normally
nobody uses ssl locally ;).



More information about the Twisted-web mailing list