[Twisted-web] /freeform_post!!random causes exceptions
Valentino Volonghi aka Dialtone
dialtone at divmod.com
Mon Jan 10 10:39:33 MST 2005
On Mon, 10 Jan 2005 18:03:40 +0100, Andrea Arcangeli <andrea at cpushare.com> wrote:
> 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
Twisted dependency is just for this specific case. But what about depending on Atop, or on a particular xml parser or xpath implementation (I seem to recall somebody wrote another loader implementation for a templating language that he designed).
There's also the chance to be depending on PIL or something else.
The package would be very eterogeneous in dependancies and I don't think that giving Nevow so many of those will help, whereas creating an external package (which can also install itself under nevow.extras) could be a good solution.
> 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).
You can also provide an hook for an action to take place once the exception is raised. This could be also accepted in Nevow probably.
> 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 ;).
This is good feedback for jamwt probably :)
More information about the Twisted-web