Jack Moffitt <jack@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