[Twisted-web] Re: some questions about twisted.web

[David Bolen]

Jack Moffitt <jack at chesspark.com> writes:

> Now I've just deluged the poor user with lots of factory start and
> stops.  All I want is normal HTTP style logs.  Twisted's logging
> infrastructure has its place, but it is not quite ready to produce
> user friendly output for a simple utility.

I generally just use the default logging but then it's mostly for my
own use, not end users.

As an interim to any more extensive changes, perhaps you could just
use a local HTTPFactory subclass for your site, overriding with your
own log method that bypasses the twisted logging to do whatever you
want?

You could then use twisted logging (if preferred) for lower level logs
and do some higher level stuff for user logging.
If you're looking for 

> Great, now the user has to edit a tac file just to configure the
> thing.  I'd rather them be able to type "tape" and not have to worry
> about twistd -ny some.tac.  I use tac files a lot, but they don't make
> much sense for simple utilities.  It sucks that it's either/or with
> Twisted applications.

For what it's worth, I've just never seemed to get into any of the
services or applications stuff with twisted.  It's certainly not a
requirement to run a server.  You can implement your own daemon
support on a Unix platform, or run as a service under Windows or
whatever.

There's nothing stopping you from just instantiating the right factory
classes, associating them with a port and running the reactor.  That
can then be a single python module that gets run directly, or if built
into an application (such as py2exe on Windows), executed directly.

I normally have more than just the web server running in a single process,
but all you'd probably need is to instantiate your "Site" class, connect
it with reactor.listenTCP, and then sit in reactor.run().

> I grok Twisted just fine.  This may be my first post to twisted-web,
> but I've been hacking on and around Twisted for some time.  Even
> Apache doesn't work this way.  I can tell apache that my proxy is at
> /some/url/over/here and it will work.  It will return 404s for the
> intermediate URLs.  Because Resources only have immediate children and
> paths are only dealt with in single element pieces, there doesn't seem
> to be a way to do this in Twisted Web.  It feels weird that the tree
> must be complete.  It feels weird that paths are dealt with in tiny
> sections.

As another view on this point, for me, I find the "work segment by
segment" approach of twisted's to be very natural, albeit different
than an arbitrary path mapping mechanism such as apache or many web
frameworks.  I actually missed the incremental lookup mechanism when
first working with django on a project, for example. It can feel weird
compared to other mechanisms, but just because it doesn't match how
Apache works need not make it a problem.  There's more than one way to
navigate an object hierarchy within a server based on the URL in a
request.

Since it's inherently simple in terms of using the getChild* methods
(or resource.getChildForRequest helper function), it's easy to
override to make very dynamic sites, which I guess I find myself doing
more often than not.  It can be very flexible when it comes to
dynamically picking the resource to handle a request.

Yes, for a static (URL wise) portion of a site you do need to
construct a "tree" of resources, so I just generally do that at
initialization time.  At worst you can stub out any piece of the tree
with a plain old Resource object to which you can add further
children.

That's not so say supporting a more "mapper" based approach on top of
this might not be useful, if only to assist people more used to that
approach.  But I definitely wouldn't want to lose the dynamic
capabilities provided by the current system.

One way to tie into the current framework to take more control is to
define the resource at the root of your mapper-capable tree using
"isLeaf".  That resource's "render" method will then get called for
any URLs at that point or below, have access to the full URL (already
split into segments), and it can do whatever lookups/mapping to
resource objects it might like.  I've used that to strip out URL
prefixes (such as client keys unique to them) and then re-perform the
URL lookup to locate the resource, but it could just as easily do a
mapper based URL lookup at that point to yield the right resource
object to then call (instantiating it if needed) to render the
request.

-- David