Mailman 3 September 2004 - Twisted-web

Test
by Philippe Lafoucrière Aug. 5, 2021

Aug. 5, 2021

Hi all just a test

3 2

How to get rid of web logs?
by Yun Mao Jan. 6, 2005

Jan. 6, 2005

Right now I'm using the log for debugging, and I don't wan to log those info like below. How should I achieve this? Thanks! 2004/09/30 13:31 Eastern Daylight Time [HTTPChannel,1,127.0.0.1] 127.0.0.1 - - [ 30/Sep/2004:17:31:56 +0000] "GET /?view=all HTTP/1.1" 200 2767 "http://localhost :1083/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3" Yun

3 3

A more Twisted approach to async apps in WSGI
by Phillip J. Eby Oct. 5, 2004

Oct. 5, 2004

Hi all. I've been away for a few days due to loss of e-mail service when my dedicated server lost a hard drive. Unfortunately my ISP didn't support the OS version any more, so I had to rebuild everything for the new OS version. Anyway, on to the topic of my post. Should 'wsgi.input' become an iterator? Or should we develop a different API for asynchronous applications? On the positive side of the iterator approach, it could make it easier for asynchronous applications to pause waiting for input, and it could in principle support "chunked" transfer encoding of the input stream. However, since we last discussed this, I did some Googling on CGI and chunked encoding. By far and away, the most popular links regarding chunked encoding and CGI, are all about bugs in IIS and Apache leading to various vulnerabilities when chunked encoding is used. :( Once you get past those items (e.g. by adding "-IIS -vulnerability" to your search), you then find *our* discussion here on the Web-SIG! Finally, digging further, I found some 1998 discussion from the IPP (Internet Printing Protocol!) mailing list about what HTTP/1.1 servers support chunked encoding for CGI and which don't. Anyway, the long and short of it is that CGI and chunked encoding are quite simply incompatible, which means that relying on its availability would be nonportable in a WSGI application anyway. That leaves the asynchronous use case, but the benefit is rather strained at that point. Many frameworks reuse the 'cgi' module's 'FieldStorage' class in order to parse browser input, and the 'cgi' module's implementation requires an object with a 'readline()' method. That means that if we switch from an input stream to an iterator, a lot of people are going to be trying to make sensible wrappers to convert the iterator back to an input stream, and that's just getting ridiculous, especially since in many cases the server or gateway has a file-like object to start with. So, I'm thinking we should shift the burden to an async-specific API. But, in this case, "burden" means that we get to give asynchronous apps an API much more suited to their use cases. Suppose that we did something similar to 'wsgi.file_wrapper'? That is, suppose we had an optional extension that a server could provide, to wrap specialized application object(s) in a fashion that then provides backward compatibility to the spec? That is, suppose we had a 'wsgi.async_wrapper', used like this: if 'wsgi.async_wrapper' in environ: controller=environ['wsgi.async_wrapper'](environ) # do stuff with controller, like register its # methods as callbacks return controller The idea is that this would create an iterator that the server/gateway could recognize as "special", similar to the file-wrapper trick. But, the object returned would provide an extra API for use by the asynchronous application, maybe something like: put(data) -- queue data for retrieval when the controller is iterated over finish() -- mark the iterator finished, so it raises StopIteration on_get(length,callback) -- call 'callback(data)' when 'length' bytes are available on 'wsgi.input' (but return immediately from the 'on_get()' call) While this API is an optional extension, it seems it would be closer to what some async fans wanted, and less of a kludge. It won't do away with the possibility that middleware might block waiting for input, of course, but when no middleware is present or the middleware isn't transforming the input stream, it should work out quite well. In any case, the implementation of the methods and the iterator interface are pretty straightforward, either for synchronous or asynchronous servers. What do y'all think? I'd especially like feedback from Twisted folk, as to whether this looks anything like the right kind of API for async apps. (I expect it will need some tweaking and tuning.) But if this is the overall right approach, I'd like to drop the current proposals to make 'wsgi.input' an iterator and add optional 'pause'/'resume' APIs, since they were rather kludgy compared to giving async apps their own mini-API for nonblocking I/O. Comments? Questions?

4 5

nevow/stackless bugs -- patch
by Peter Hunt Oct. 3, 2004

Oct. 3, 2004

I've been trying to run stan on stackless when I ran into a problem with render methods. Stackless uses "stackless.instancemethod" instead of "__builtin__.instancemethod", and "stackless.function" instead of "__builtin__.function". Attached is a svn diff patch of the changes I made to __init__.py in order for stan to support stackless properly. HTH, Peter Hunt

3 3

need some help
by Bartek Bargiel Sept. 30, 2004

Sept. 30, 2004

My question may sound weird but I have no ideas about it... If there are users of Internet Explorer and Mozilla Firebird around please use both browsers to enter my website at http://www.itabak.com/start Please pay attention to strange behaviour of IE. It seems to stop downloading site but suddenly it displays the whole page. There's no action like that in Firebird's case. I'm not sure if it's anything related to twisted.web or is it just IE page layouting problem. I'll be glad for all comments. BTW: thanks for Unicode help! Regards, -- Bartek Bargiel

1 0

Serving files from many web-servers thru one central web-server
by Thomas Weholt Sept. 29, 2004

Sept. 29, 2004

Hi, I got a subnet full of web-servers using twisted and a main web-server based on twisted as well. The main server is available to the outside world. I want to serve files on the other web-servers on the subnet thru the main web-server. There may be many concurrent users on the main server so it has to be able to handle many clients. A few users connect to the main server, requesting files on the subnet web-servers. The main server reads data from several subnet servers and writes the data back to the requesting clients. How can I do this in twisted, without blocking, and handle several clients? We're not talking hardcore P2P here with thousands of clients, most likely 2-5 concurrent users, 10 at the most. Any hints? Or doesn't this make any sense? -- Mvh/Best regards, Thomas Weholt http://www.weholt.org

2 5

adding etag and modified arguments to twisted feedparser
by Selwyn McCracken Sept. 29, 2004

Sept. 29, 2004

hi, I am having trouble modifying the twisted-based rss aggregator from the python cookbook so that feedparser can make use of the update related arguments of 'etag' and 'modified' to save bandwith. (see http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277099) I realise that the problem is deferred related, but I can't seem to resolve the problem, even after reading the deferred documentation. Anyway, the series of deferred functions that I think are relevant are: 1) def getPage(self, data, args): #args is the rss feed link return client.getPage(args,timeout=TIMEOUT) 2) def parseFeed(self, feed): parsed = feedparser.parse(cStringIO.StringIO(feed)) The problem is that getPage() requests the entire rss feed, and then passes the stream through to feedparser.parse. Normally however, feedparser.parse() takes furthers arguments of 'etag' and 'modified' so that only new feed information is returned, thereby saving bandwidth. I tried modifying getPage() to return feedparser.parse(args), and removing the need for parseFeed(), but it runs substantially slower than the original method, I presume in a synchronous manner. Any assistance in helping to restore the impressive parallel downloading performance, but with the the datetime arguments included, would be greatly appreciated. many thanks, Selwyn

3 5

Remembering things in context from a Realm
by Alex Levy Sept. 28, 2004

Sept. 28, 2004

I have a Realm class that does something akin to the following: class MyRealm: def requestAvatar(self, id, mind, *interfaces): if IResource is in interfaces: user = figureOutWhoTheUserIs(id) resource = getResourceForUser(user) resource.remember(user, ICurrentUser) return (IResource, resource, lambda:None) ...and this doesn't seem to be working with the ubiquitous context. _Should_ it work, or do I need a new way to do something like this? Help is appreciated; I'm trying hard to get back in the loop. :/ -- Alex Levy WWW: http://mesozoic.geecs.org/ "Never let your sense of morals prevent you from doing what is right." -- Salvor Hardin, Isaac Asimov's _Foundation_

3 5

nevow 0.3 + encoding
by Bartek Bargiel Sept. 28, 2004

Sept. 28, 2004

Hi! My first comment after having installed Nevow 0.3: my polish cp1250 encoding chars are not displayed: - htmlfile replaces them all with question marks (it works OK when using UTF-8 encoding) - xmlfile works fine when reading the text from file but again it fails to display national charset when it gets it returned from Python code Maybe it's me doing something wrong somewhere, I'm getting more&more confused with that encoding stuff :) Bartek Bargiel

2 1

Re: Nevow status
by Donovan Preston Sept. 27, 2004

Sept. 27, 2004

On Sep 27, 2004, at 1:57 PM, Marc-Antoine Parent wrote: > I wrote some for the hell of it. Page patterns and children factories > are dead easy; working my way through the forms logic right now. My > only comment so far: I wish adding events did not require writing an > interface. (Or does it? Don't answer if you're busy, I'll figure it > out ;) > > I expected something like > class myPage(rend.Page): > def action_someAction(self, ctx, *kwargs): > .... > > so that I could call, in a simple href or form: > myPage?action=someAction&arg1=1&arg2=b > I know formless and/or liveEvil are better ways to do some of this, > but I like calling a RESTful interface from Javascript to transmit > data to the server. > I may just code it atop what is there, it looks easy enough ;-) > If there are deep reasons _not_ to do it, I'd like to know. I'm ccing this to the list to solicit more general feedback. I agree it should be easier and it's something I have been thinking about for a little while now. The main reason formless requires interfaces is because of the type annotation, coercion and error handling features of formless. If you are just submitting strings and don't care if they are valid or not it would be easy enough to do what you want to do: class ActionPage(rend.Page): def renderHTTP(self, ctx): action = ctx.arg('action') if action: args = IRequest(ctx).args.copy() del args['action'] return getattr(self, 'action_%s' % action)(ctx, **args) return rend.Page.renderHTTP(self, ctx) I might go ahead and add this to rend so people can use it if they want. The thing I like about this approach is that it is simple enough to get started quickly, since formless is a lot to swallow when you are learning the framework. I still think the formless interface approach is valid and useful however, because of all the things you get from it: * Form rendering * Error checking * Error form rendering * Type coercion * Method calling and property setting Really, formless is designed as the ultimate REST architecture, where form POSTs only mutate server side objects and are immediately redirected to a GET for that same object. But it is overkill for simpler tasks. Maybe there should be some sort of middle ground. dp

1 0

Implement "Page Not Found "
by Tsai Li Ming Sept. 27, 2004

Sept. 27, 2004

Dear All How do I implement a 404 Page Not Found using twisted web for those resources that I did not add using putChild? class Server(resource.Resource): def getChild(self, name, request): if name == '': return self return Resource.getChild(self, name, request) Thanks, -Liming

1 0

Nevow 0.3
by Donovan Preston Sept. 27, 2004

Sept. 27, 2004

Nevow 0.3 is out. Get it from http://nevow.com/releases/0.3.0/ Thanks to everyone for all their hard work over the last 5 months! I'm very proud of this release. dp

1 0

web2
by William Dode Sept. 25, 2004

Sept. 25, 2004

hi, Is there somewhere a paper on the plan of web2 ? I mean the goal of web2 and the differences with web1. I think it will help us to understand why web2 need nevow. -- William - http://flibuste.net

8 10

web2 cleanup
by Donovan Preston Sept. 25, 2004

Sept. 25, 2004

Well, I finally got a chance to look at web2 tonight, and as I did I just did whatever random cleanups seemed appropriate. Patch attached, and I will commit unless there is any objection. It's pretty obvious to me that web2 is going to need some pretty major scrubbing before release to remove the stench of web. James, we should coordinate some time on IRC when we can both talk about and work on this. I need to devote some energy to this before Twisted 2.0.

1 0

many virtual hosts -> separate log files
by Bartek Bargiel Sept. 25, 2004

Sept. 25, 2004

hi there! :) let's assume I'm running a single twisted.web server with many vhosts served. Please tell me how to log requests to separate log files depending on requestHostname detected? regards, -- Bartek Bargiel

1 0

session expiration
by Bartek Bargiel Sept. 23, 2004

Sept. 23, 2004

Hi! I was looking for a possibility to set session timeout - I found this timeout hardcoded in twisted.web.server module. Shouldn't it be more flexible? ;-) -- Bartek Bargiel

2 1

Re: [Twisted-Python] Fwd: [Twisted-commits] r11721 - revert r11685
by Cory Dodt Sept. 20, 2004

Sept. 20, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Urgh. I usually avoid getting involved in these discussions--not because I don't want to participate but because the ML style does not work very well with my brain. There's all these different parts of this proposal and some are being rejected by some people and modified by other people and it's very hard for me to figure out what the whole picture is. In this case, I have to say something because this is pretty important to the product I'm developing. I just spent 6 weeks doing a conversion to Nevow because Woven isn't being supported any more. I do *not* want to do the same thing with Web. I've made modifications to Twisted trunk that I was hoping to get out of 2.0 for our official release, but if there's not going to be a web1 any more, that puts this project in jeopardy again because it means I may not be able to use 2.0. So here's what I have to say: please *summarize*. I need to get a sense of: 1) Timeline.. when are changes being implemented, in what order, tied to what release etc. 2) How is the svn repo going to change? 3) What is going to be put into what release by whom? 4) What's the impact if you're currently using web1 and you want to be using web2 because 1 isn't supported any more? 5) What's the impact if you stay with web1? If you haven't decided yet, go ahead and decide, but then summarize afterwards. :-) Thanks.. C Itamar Shtull-Trauring wrote: | On Mon, 2004-09-20 at 10:49, Glyph Lefkowitz wrote: | | |>>We already figured out which web server we ("we" being those developers |>>who actually care about the web) are going to be supporting. |>>twisted.web2. web should have a deprecation warning in __init__ for a |>>release, and then should be terminated with extreme prejudice. |> |>I would terminate before providing a deprecation warning. If you want |>to provide a backwards-compatibility release for using web1 with the new |>reactor core, that's fine, but I don't see any reason to include web1 |>with the new download. | | | twisted.web will not be included. There will be two downloads ("Twisted | Web 1 - Deprecated", "Twisted Web 2"). Most people will not download the | first ever. The first will likely not have new releases unless we fine | security issues. Moving it to branch and only doing releases from there | may be fine (if our release infrastructure is up to it!) but I still | think newweb should be twisted.web2. | | | Summary: | | 1. twisted.web2 remains web2. | 2. Move twisted.web (and any other security bugfix only packages, I | guess) to a "deprecated" branch. | | Yes? No? | | If yes, that just leaves the nevow/twisted.web2 merger question, which | should probably be done on twisted-web mailing list. | | | | _______________________________________________ | Twisted-Python mailing list | Twisted-Python(a)twistedmatrix.com | http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBTvtx3A5SrXAiHQcRApINAKCggxacS+kFLmAszBQmrQeuByJHBgCgnyov jBEWFaH7dZ6TZBbtljvVZTg= =tLpe -----END PGP SIGNATURE-----

2 1

Re: [Twisted-web] Re: [Web-SIG] WSGI woes
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

At 10:41 PM 9/16/04 +0100, Alan Kennedy wrote: >In this way, there could be a middleware component below the >rot13_streamer in the stack that, say, does chunked_transfer encoding and >decoding. It would be the same in form as the above, except that it would FYI, middleware and apps are now banned from dealing in any kind of transfer-encodings, per James' very valuable input on that subject. Like connection properties, these should be the exclusive province of the actual web server. >1. Change the environ entry for 'wsgi.async_input_handler' to be its own >callable that records the callback for the next layer up in the stack, the >rot13_streamer.input_handler. This would lead to the unacceptable situation of every middleware component having to know in principle about extensions. The "Server Extension APIs" section of the PEP demands that any "bypass" API verify replacement for this very reason. >I think that this proposed approach is clean, and not overly complex for >async or blocking programmers to handle. Unless of course they're writing middleware that does something with the input. >But I think we do have to cleanly separate the two. I think there are >problems associated with trying to run *all* components seamlessly across >async or blocking servers. I think that middleware components that are >always going to behave correctly in an async situation will have to be >designed like that from the ground up. It's dangerous to take components >written in a blocking environment and run them in an async environment. It is a non-goal for WSGI to support running multiple requests simultaneously in a single-threaded asynchronous server, so the issue doesn't really come up. A WSGI server *must* allow for the fact that WSGI apps use up a thread while they're running or producing a value: that's the price of being able to run "traditional" web applications under WSGI. >And lastly, if it is desired to spin jobs into a different thread, e.g. >the rot-13 job above, then that should be a middleware concern, not the >WSGI server's. I agree with you -- for *asynchronous* applications. Synchronous web applications are the default case in WSGI and the world in general, so servers *must* use a thread pool to start applications and to run 'next()' calls, if they are asynchronous. But, asynchronous applications wish to yield control, to avoid hogging resources in that thread pool, so they need to delegate the work to their I/O thread, and then yield an empty string to pause output, freeing up that thread for another iterable next(), or application start. Notice, however, that if the server is *synchronous* (e.g. CGI, single-threaded FastCGI containers, mod_python under Apache 1.x, etc., ), then this is a complete waste of time, because you'll only be running one simultaneous request in this process anyway, so you're spinning off a second thread to keep from tying up the first thread, but all the first thread is doing is waiting for the second thread to finish! This is wasteful, to say the least. The only case where pausing output (whether for unrelated network I/O, or because of a need to read from the input stream) is actually useful is when the server is *also* asynchronous -- hence the value of making such pausing an optional extension API. The application can then detect when it's *useful* to pause, and synchronous applications needn't worry about it. Of course, even if the server and application are *both* asynchronous, that's no guarantee that they're using compatible event loops! If you try to run a Twisted app under asyncore or vice versa, you're going to be spinning off an extra thread to run a second event loop, so there's a bit of a trade-off to determining whether your asynchrony is going to actually *gain* anything. But that's a separate question. WSGI will allow you to be asynchronous if you really want to, no matter how bad an idea it might be in some cases. :) >The twisted rot-13 component would then have very thin methods (run from >the server's main thread) which interact with the twisted space i.e. >transferring data and receiving data back through queues, and layer WSGI >semantics on those interactions, i.e. pause_output, yield result, yield >empty_string, etc. You're pretty much describing what I suggested earlier: that async app frameworks like Twisted may want to have a model whereby a generic "thin wrapper" WSGI application object is used to communicate with an application that's written using the underlying framework's async idioms. So, for example, one might perhaps design a Twisted "Transport" that was implemented as a WSGI application. (I don't know if "Transport" is really the correct abstraction to use, I'm just giving an example here.) Anyway, for such a thing to really work, I think you might need server-specific reactor plugins, to integrate Twisted's event loop with that of the server. >When I described your approach as "pulling data up the stack", I saw a >bigger difference between the two approaches. I'm thinking now that there >is little difference between our proposals, except that in mine it's the >bottom component that gets notified of the input by the server, and in >yours it's the top component. Though I suppose having the top component >pulling input from an iterator chain mirrors nicely the situation where >the server pulls output from an iterator chain. Actually, I'm saying you pull data *down* the stack. The bottom-most application iterator calls 'read()' on an input stream provided by a parent middleware component, which then calls read on a higher-level component, and so on. >And my approach basically entails a bunch of nested calls, which might be >less efficient elegant than if, say, generators were used in an input >processing chain. > >You're right again Phillip :-) Not entirely, actually. For my approach to really work, the middleware would have to be guaranteed to return something from read(), as long as the parent's read() returns something. Otherwise, the resumption would block, unless the middleware were much smarter. I've got to think about it some more, because right now I'm still not happy with the specifics of any of the proposals for pausing and resuming output.

1 1

Re: [Twisted-web] Re: [Web-SIG] WSGI woes
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

At 08:29 PM 9/16/04 +0100, Alan Kennedy wrote: >[Alan Kennedy] > >> In an asynchronous situation, the application cannot simply do a > >> blocking read on the input: that will tie up the server thread. > >[Phillip J. Eby] > > What do you mean by "server thread"? A truly asynchronous server (one > > using "no threads") cannot serve multiple WSGI requests > > simultaneously. In the general case, a WSGI server can only serve as > > many requests simultaneously as it has available threads for. > >Sorry, I should have paid more attention to phrasing in this context. > >By "server thread" I mean the thread of execution that is running the >select/poll operation in the server (which needs at least *one* thread). >If the application did a blocking read of the input running in a simple, >single-threaded asyncore-style server, that single thread would block, >holding up event processing. Right, which is (one reason) why a WSGI server can in the general case only serve as many WSGI requests simultaneously as it has available threads for, although it's possible to improve on that worst-case condition by appropriate use of iterators. >But I don't see the need for pausing logic or queues? Why can't the server >simply call directly into the application, e.g. using a "process_input" >method, in effect saying "you have some input ready". > >And I'm not sure I see the need for the application to check that the >wsgi.input hasn't been replaced: if there were middleware further down >that stack that was intercepting and transforming the input stream, then >*it* should be the one receiving the asynchronous notification from the >server. This lower level component would then read some input, process it, >and then call a "process_input" method on the next component up in the >stack, etc, etc. > >I suppose I'm talking about the server "pushing" the input through the >middleware stack, whereas you're talking about the application at the stop >of the stack "pulling" the data up through the stack. Is that right? That's correct, and that's what I'm trying to avoid if at all possible, because it enormously complicates middleware, to the sole benefit of asynchronous apps -- that mostly aren't going to be portable anyway. So, going by STASCTAP theory (Simple Things Are Simple, Complex Things Are Possible), the pause/resume approach makes asynchronous applications *possible*, while keeping the nominal synchronous cases and middleware *simple*. >And I'd be interested to see how your approach would handle a situation >where there is both streaming input and output. For example, a server that >takes strings of any length, say 10**9 bytes, and .encode('rot13')'s each >byte in turn, before sending it back to the client. Presumably, the function to pause for input needs to take a minimum length, or have some way to communicate available length to the application. I don't pretend to fully understand the needed use cases here, because I have little experience writing web applications that need to wait on other network services (other than databases) while a client is waiting. And if I were writing an asynchronous server, I'd probably at least consider using Greenlets to context-switch blocking operations so that they wouldn't tie up an active thread. Such an approach is conceptually easier to deal with, IMO, than writing everything in continuation-passing style. But I *do* want WSGI to make it *possible* to meet async apps' use cases, which is why I'm seeking input from those that do have the relevant experience. The trade-off is that it shouldn't excessively complicate nominal compliance with WSGI. In particular, I'd prefer that the current "example CGI gateway" in PEP 333 not require any major changes or significant expansion.

1 0

Draft language for WSGI to forbid blocking by middleware
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

I'm proposing the following language to be added to PEP 333, as a subsection under "Buffering and Streaming", just before the subsection entitled, "The write() callable". It doesn't address pausing or resuming iteration (which I don't have a PEP-able proposal for yet), but it should ensure that middleware doesn't introduce any additional blocking issues: ===excerpt start=== Middleware Handling of Block Boundaries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to better support asynchronous applications and servers, middleware components **must not** block iteration waiting for multiple values from an application iterable. If the middleware needs to accumulate more data from the application before it can produce any output, it **must** yield an empty string. To put this requirement another way, a middleware component **must yield at least one value** each time its underlying application yields a value. If the middleware cannot yield any other value, it must yield an empty string. This requirement ensures that asynchronous applications and servers can conspire to reduce the number of threads that are required to run a given number of application instances simultaneously. Note also that this requirement means that middleware **must** return an iterable as soon as its underlying application returns an iterable. It is also forbidden for middleware to use the ``write()`` callable to transmit data that is yielded by an underlying application. Middleware may only use their parent server's ``write()`` callable to transmit data that the underlying application sent using a middleware-provided ``write()`` callable. ===excerpt end=== In addition to this insertion, I would modify the 'start_response()' specification to note that HTTP headers should not be sent until the first *non-empty* string is yielded from the iterable. Comments?

1 0

Re: [Twisted-web] Re: [Web-SIG] WSGI woes
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

At 05:45 PM 9/16/04 +0100, Alan Kennedy wrote: >The only thing I disagree on are the names "sleep" and "wake", which IMHO >come with too many semantic hangovers from the threading world. When an >application calls wsgi.sleep(), it's not really sleeping, it's just >declaring that it currently has no output: a call to its iterator will >succeed, but the returned value will be an empty string. > >So basically, WSGI is providing an on/off indicator for every instance of >a middleware stack, which indicates to the server if there is currently >output available. Well, I'm proposing it as an optional extension, not a required feature. And, I think I'd like to streamline it to a single 'wsgi.pause_output' function, e.g.: resume = environ['wsgi.pause_output']() Where 'resume' is then a callback function that can be invoked to resume iteration. This keeps it to a single extension key, helps ensure the correct sequence of actions, and makes it easier to implement in some cases, while not making other cases any harder. >In an asynchronous situation, the application cannot simply do a blocking >read on the input: that will tie up the server thread. What do you mean by "server thread"? A truly asynchronous server (one using "no threads") cannot serve multiple WSGI requests simultaneously. In the general case, a WSGI server can only serve as many requests simultaneously as it has available threads for. However, WSGI applications that use iteration in place of 'write()' can sometimes be run with fewer than one thread per simultaneous request -- that's why iteration is recommended for applications that can be implemented that way. > So we need a way for the application to be notified/called when input > becomes available from the client. > >Perhaps we need to add an environment entry, e.g. "wsgi.input_handler", >which the app uses to pass a callable to the server. This callable would >be called whenever data became available on the input stream. > >So how would that work in the middleware stack? You would have to pass either 'environ' or 'wsgi.input' *into* this input handler request function, so that the server can verify it hasn't been replaced by any middleware. This is the standard way in WSGI of providing enhanced communication facilities that could "bypass" middleware. See: http://www.python.org/peps/pep-0333.html#server-extension-apis So, in principle, if the spec is modified to require middleware to honor child applications' block boundaries, then you could use an extension API to pause iteration until input is available, in much the same way that you would pause iteration for any other reason. Neither of these "pause iteration" solutions are especially elegant, at least from the POV of an async application author. But my objective here is only to make it *possible*, not necessarily pretty. I imagine that if there's actual demand for async apps to run under WSGI, it should be possible to create wrappers to let an application written in Twisted's continuation-passing style be run as a WSGI app. Such a wrapper would basically be just a function returning an iterator, with a bunch of pausing logic and a queue to communicate with the actual asynchronous app. And, such wrappers should only need to be written once for each asynchronous API, which as a practical matter probably means only Twisted, anyway, as (IMO) it has no real competitors in the Python async framework space.

1 0

Re: [Web-SIG] WSGI woes
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

At 06:48 PM 9/15/04 -0400, Peter Hunt wrote: >It looks like WSGI is not well received over at twisted.web. > >http://twistedmatrix.com/pipermail/twisted-web/2004-September/000644.html Excerpting from that post: """The WSGI spec is unsuitable for use with asynchronous servers and applications. Basically, once the application callable returns, the server (or "gateway" as wsgi calls it) must consider the page finished rendering.""" This is incorrect. Here is a simple WSGI application that demonstrates yielding 50 data blocks for transmission *after* the "application callable returns". def an_application(environ, start_response): start_response("200 OK", [('Content-Type','text/plain')]) for i in range(1,51): yield "Block %d" % i This has been a valid WSGI application since the August 8th posting of the WSGI pre-PEP. It may be, however, that Mr. Preston means that applications which want to use 'write()' or a similar push-oriented approach to produce data cannot do so after the application returns. If so, we should discuss that use case further, preferably on the Web-SIG. >I thought the blocking call was handled by the iterator, but maybe I'm wrong. I'm not sure what you mean, but if you're asking whether the iterable is allowed to create output blocks after the application callable returns, then yes.

3 4

Re: [Twisted-web] Re: [Web-SIG] WSGI woes
by Phillip J. Eby Sept. 16, 2004

Sept. 16, 2004

At 03:59 PM 9/16/04 +0100, Alan Kennedy wrote: >And, of course, that's what we're really discussing here: server >scheduling, and how servers ensure that application output gets >transmitted to clients with maximum efficiency and timeliness. IMHO, >asynchronous server scheduling algorithms and concerns have no place in >core WSGI, although a well-designed optional extension to support effiency >might have a nice unification effect on python asynchronous server >architectures. Right. I'd encourage people to experiment with async extensions like my sleep/wake idea, and if there's sufficient consensus we could add a "standard extension" to the spec. But I don't want to disturb the write()+iterable model, since that allows middleware to be mostly oblivious to the sync/async issue, and only apps or servers that care have to deal with it. While asynchronous servers are fairly common, most existing asynchronous applications are going to be tied to a particular async server architecture no matter what we do in WSGI.

1 0

Re: [Web-SIG] WSGI - alternate ideas, part II
by Peter Hunt Sept. 16, 2004

Sept. 16, 2004

I think that the application should be passed a finish() method as a parameter or start_response return value. If the WSGI application is not a generator and returns wsgi.NOT_DONE_YET (similar to Twisted.web's NOT_DONE_YET), it is required to call finish(). Otherwise, the gateway will call finish() after the generator is finished or a string value is returned. That way, one could do all of the deferred calls they want, and simply return NOT_DONE_YET and call finish(). How does that sound? On Wed, 15 Sep 2004 23:27:18 -0400, Phillip J. Eby <pje(a)telecommunity.com> wrote: > At 11:06 PM 9/15/04 -0400, Peter Hunt wrote: > > >Thus, here is my "WSGI-X" proposal. The application will call the > >gateway, opposite of WSGI. For example, a CGI WSGI-X application may > >begin with: > > > >#!/usr/bin/env python > >if __name__ == "__main__": > > from wsgix import cgi > > req = cgi.get_request() > > That's pretty hard to implement correctly in any number of > servers. Really, pretty much every server wants to call the application, > rather than the other way around, because servers want to use their own > event loop. > > > >stdout - the raw, unbuffered direct output stream to the client > > So, header parsing is required? Or are only 'nph-' CGI scripts allowed? > > > >Now we have a basic interface to interact with HTTP. If one wants to > >write an extension to provide services like simplified cookie > >handling, sessions, or buffered headers and content, they write an > >extension function. A simple one for cookies would look like: > > > >def cookie_extension(req): > > if not hasattr(req, "cookie"): > > req.cookie = > > Cookie.SimpleCookie(req.environ.get("HTTP_COOKIE","")) > > Note that this can easily be accomplished in WSGI, by changing > 'hasattr(req,"cookie")' to '"my_extension.cookie" in environ' and > 'req.cookie' to 'environ["my_extension.cookie"]'. > > > >It modifies the request object if it hasn't already been modified. > >This saves us a bit of overhead so we won't need to parse the cookie > >again in case it is called twice (as it will if other extensions > >depend on it). > > Also achievable within 'environ'. > > > >Finish hooks have the same signature and execute when > >the finish() method is called. For example, a buffering extension > >would flush the buffer. Extensions can also add methods to the request > >object, for items such as add_header(). > > Under WSGI, such "finish" hooks can be rendered as a 'close()' method on an > iterable by a piece of middleware. > >

3 2

Adding data to the request
by Syver Enstad Sept. 16, 2004

Sept. 16, 2004

Is there a supported way for adding data to a twisted.web request object. I am not thinking about the session, because I only want the data to last the current request, the typical use is for a resource to add some data that would be used by a child resource. I know I could use the args dictionary but that seems a little awkward as that is supposed to contain the query string/post for the page.

2 4

Twisted.web2
by James Y Knight Sept. 16, 2004

Sept. 16, 2004

Itamar and I had dinner today and talked about new-web a bit. Here is what was discussed: 1) We need to keep compatibility with old Nevow resources 2) We ought to keep compatibility with old twisted.web resources 3) The new request API isn't the same as old request API. 4) new-web depends on Twisted 2.0. Nevow will be depending on new-web, so the next Nevow will depend on twisted 2.0. Thus it cannot be released until Twisted 2.0. According to itamar the goal for next Twisted release is around halloween, although I hadn't seen that mentioned anywhere before. ;) 5) Rumors are Anthony is writing a non-sucky HTTP client. (is this true?). J. Simms (slyphon) mentioned something about writing one to me a few weeks ago but I didn't hear anything after. This should be coordinated so the API for the client and server is as similar as possible. Conclusions for action: 1) new-web will be called twisted.web2. I will put what I've got into svn trunk as twisted.web2 tomorrow, assuming no objections. This will allow easy backwards compatibility at the cost of a 2. 2) Nevow's resource traversal API must be moved to twisted.web2. This will probably have to be done by branching Nevow to remove those bits. Therefore, the resource traversal part of nevow should be mostly-frozen while this happens. 3) For distribution: twisted.web2 depends on Nevow (for static directory listings, and error pages), so will be distributed with it. Nevow recommends Twisted but does not require it for simple cases (e.g. flattening to a string from a CGI script), so there can also be a limited-functionality distribution of standalone Nevow. Current status of new-web: the low-level HTTP protocol and header parsing is in passable shape. The high-level Resource API needs to be copied over from Nevow (again), because Nevow's API changed. Backwards compatibility adapters for the t.w.Request/nevow.inevow.IRequest and (possibly) nevow.inevow.IResource should be added. I am not able to do everything myself. I will need help, especially from dp would be helpful for the Nevow transition, to make this happen. If we do it right, twisted.web2 might even be ready in time for the release of Twisted 2.0. James

3 4

Partial freeze of nevow coming up.
by James Y Knight Sept. 15, 2004

Sept. 15, 2004

Here's the plan. The following modules will be removed from Nevow, and merged/copied/whatever into twisted.web2: appserver.py static.py half of context.py dirlist.py failure.py guard.py static.py vhost.py url.py, perhaps. I want to create a nevow web2 integration branch, and while they are being removed from Nevow, and merged back into web2, I don't want the Nevow copy radically changing cause that just creates extra work. So if there's any changes you want to make to any of those, please do it soon. The rest of Nevow can continue changing during the transition without problem. Sidenote: Divmod needs to approve the relicensing of the code that moves into web2 from nevow under MIT license. Or else move all of Nevow under MIT license. James

2 1

url.URL.fromRequest gives unexpected behaviour
by Matt Goodall Sept. 15, 2004

Sept. 15, 2004

Hi, URL.fromRequest() currently creates a URL for the path segments that have been resolved so far. That means that creating a URL in locateChild and a rend_* method gives you a different URL. That's unexpected. I think we need more explicit ways of creating a URL to allow for different usecases: URL.fromString(aStr) create a URL from the string. this is already implemented URL.fromRequestURI(aRequest) create a URL that matches the request exactly URL.fromContext(aContext) create a URL for handled path segments. kind of like the url.here overlay but not so lazy. A better name for fromContext might be fromLocation, fromSegment, etc. We can deprecate URL.fromRequest but, until it's removed, make it call fromContext. Cheers, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt(a)pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.

2 2

Re: [Twisted-web] separate sites and server
by Bartek Bargiel Sept. 14, 2004

Sept. 14, 2004

> I have been using twisted.web.proxy to do something similar, but it has > a few flaws: I've already checked out twisted.distrib. Unfortunately it didn't seem to work with Nevow - with or without vhosts. Today I quickly introduced Mary's solution mentioned above. That's what I was looking for! Thanks! :-D Bartek Bargiel

1 0

separate sites and server
by Bartek Bargiel Sept. 13, 2004

Sept. 13, 2004

Hi! Is there a way to create separate NevowSites and then 'register'/'unregister' them in a running Twisted application? My goal is to make possible to many users to run and restart their sites separately without stopping the whole system (all the apps). Note that virtual hosts mechanism is used to select the desired app. Any experiences or solutions? Regards, -- Bartek Bargiel

3 4

Dynamic annotate.Choice form elements?
by Patrick B. Day Sept. 13, 2004

Sept. 13, 2004

Say a form is to have a picklist which is defined by a database table and is dynamic (ie changes as the table changes). How do I create an annotate.TypedInterface subclass and use formless in this case? (ie How do I access the annotate.Choice element and add the choices during rendering?) Thanks, -Pat. ============================ Patrick Day uf069(a)victoria.tc.ca

1 0

Load balancing twisted web.
by Syver Enstad Sept. 13, 2004

Sept. 13, 2004

Hi! I am running a custom twisted server application that uses twisted web. To improve performance sometime in the future I am interested in scaling up by adding more instances of the server, but this requires load balancing. Very simple load balancing is likely to not work very well since I use the session facilities in twisted web. As I see it I have a couple of options: Build my own session mechanism that uses persistent storage shared by all servers (I am using ZODB already so it is easy to store objects). Get some kind of load balancer program that takes care of server affinity by remembering which server has which session id. Write a load balancer program that does the same. As far as I know load balancer hardware is out of the question since I use HTTPS and from what I have heard this is not supported my inexpensive load balancer hardware.

3 3

Add segmentsResolved method to inevow.IResource
by Matt Goodall Sept. 9, 2004

Sept. 9, 2004

Hi all, On the #twisted.web channel we've had numerous discussions about a couple of edge cases to do with resource location. Specifically: 1. The located resource is just a proxy to a real resource. Where do I return the real resource from since locateChild is not called once all segments have been resolved? A suggested solution has been to return the real resource from renderHTTP. That is conceptually wrong and also a bit awkward to support. It's also broken in svn trunk at the moment ;-). 2. I have to access to query parameters in every rend_* method. Is there a way of processing the query parameters just once so they are already available in the rend_.* methods? So far, the solution seems to be to override renderHTTP, process the query parameters (and store them somewhere) and then call up to the parent class's renderHTTP method. 3. A page displays a list of objects and each object has a delete action. What's the best way to handle the deletion? There are a few ways I have seen this implemented: use a form for each object; use a fake child URL segment and pass the object's id as a query parameter; pass the object's id as a query parameter to the list page itself (this means overriding renderHTTP because locateChild is not called, as in #1). The are probably countless other similar cases. I propose that we add one more method to the IResource API - a "hook" method that is called when the final segment has been located, i.e. there are no more path segments to process. The IResource definition of the method would look something like: def segmentsResolved(self, ctx): pass Suggestions for better names welcome. Perhaps youAreIt is better name ;-). If the result of calling segmentsResolved is None renderHTTP would be called as normal. If something not None is returned then it must be an IResource (or adaptable, deferred, blah blah blah) and will be used as the resource for that URL from then on. Hmm, I guess segmentsResolved should be called repeatedly until a None is returned to allow for proxy->proxy->proxy->real but that's just implementation. It think that should cover most use cases I have seen and, conceptually, seems much, much cleaner than what we do right now. Cheers, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt(a)pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.

2 3

Nevow Documentation
by Dan Eloff Sept. 9, 2004

Sept. 9, 2004

I've seen tentative hints that someone or some people were almost finished working on the docs for nevow. I have not found them online, however. Does anybody know where I might find them? Thanks, -Dan

2 1

Can't subclass when docFactory is a loaders.stan instance.
by Patrick B. Day Sept. 9, 2004

Sept. 9, 2004

Is there anyway when constructing a page using stan to use render_* methods which are defined in the subclass? e.g. class Template (rend.Page): docFactory=loaders.stan(T.html()[T.title()[T.span(render='title')]]) class Foo (Template): def render_title (self, ctx, data): return 'My title is Foo' If I assign a string to render (in the T.span attribute) then the string is just returned rather than a render_* method being called. If I assign a render_* method (eg 'render_title') to render then the rendering is done by calling the method in Template not in the subclass. For instance this does not work: class Template (rend.Page): def render_title (self, ctx, data): raise NotImplementedError docFactory = \ loaders.stan(T.html()[T.title()[T.span(render=render_title)]]) class Foo (Template): def render_title (self, ctx, data): return 'My title is Foo' I don't have this issue if I use loaders.htmlfile() and store my stuff in an html file. Thanks for your help. -Pat. ============================ Patrick Day uf069(a)victoria.tc.ca

2 1

Macros in Nevow
by Donovan Preston Sept. 9, 2004

Sept. 9, 2004

Implementing compile-time macros has always been on my list of things to do in Nevow, but so far I haven't needed it so I haven't bothered trying to do it. Now that nevow is getting more finished and there are fewer pressing issues for me to work on, I thought I'd give it a shot. It turned out to be pretty easy: >>> from nevow import flat, tags >>> flat.precompile(tags.html[ tags.div(macro=lambda c: c.tag.children*5)[ "Child " ]]) ['<html>Child Child Child Child Child </html>'] I'm not yet sure exactly how macro directives would be handled -- I think there would have to be an explicit type check against the type of toBeRenderedBy, followed by a ctx.locate(IMacroFactory).macro(name). This is different than how the render and data directives are simply adapters registered against the directive type, but I think it is ok. Another thing to consider would be parameterized macros similar to the parameterized renderers and data directives we can use now. However since the macro executes immediately the parameters could probably be passed directly to the macro method: <html><div nevow:macro="foo bar,baz" /></html> def macro_foo(self, ctx, bar, baz): return bar, baz (Which would result in: <html>barbaz</html>) Comments, suggestions, heckles? dp Index: nevow/flat/flatstan.py =================================================================== --- nevow/flat/flatstan.py (revision 587) +++ nevow/flat/flatstan.py (working copy) @@ -40,10 +40,17 @@ if visible and context.isAttrib: raise RuntimeError, "Tried to render tag '%s' in an tag attribute context." % (original.tagName) - + + if context.precompile and original.macro: + toBeRenderedBy = original.macro + original.macro = Unset + newContext = context.with(original) + yield serialize(toBeRenderedBy(newContext), newContext) + return + ## TODO: Do we really need to bypass precompiling for *all* specials? ## Perhaps just render? - if context.precompile and (original._specials or original.slotData): + if context.precompile and ([x for x in original._specials.values() if x is not None and x is not Unset] or original.slotData): ## The tags inside this one get a "fresh" parent chain, because ## when the context yielded here is serialized, the parent ## chain gets reconnected to the actual parents at that Index: nevow/stan.py =================================================================== --- nevow/stan.py (revision 582) +++ nevow/stan.py (working copy) @@ -77,7 +77,7 @@ which make representing trees of XML natural using pure python syntax. See the docstrings for these methods for more details. """ - specials = ['data', 'render', 'remember', 'pattern', 'key'] + specials = ['data', 'render', 'remember', 'pattern', 'key', 'macro'] slotData = None def __init__(self, tag, attributes=None, children=None, specials=None): @@ -108,9 +108,9 @@ table(width="100%", height="50%", border="1") Attributes may be 'invisible' tag instances (so that - a(href=invisible(data="foo", render=myhrefrenderer) works), + a(href=invisible(data="foo", render=myhrefrenderer)) works), strings, functions, or any other object which has a registered - ISerializable adapter. + flattener. A few magic attributes have values other than these, as they are not serialized for output but rather have special purposes @@ -151,7 +151,7 @@ """Add children to this tag. Multiple children may be added by passing a tuple or a list. Children may be other tag instances, strings, functions, or any other object which has a registered - ISerializable adapter. + flattener. This is implemented using __getitem__ because it then allows the natural syntax:

1 0

nevow FileUpload
by Williamson, Mark Sept. 8, 2004

Sept. 8, 2004

Hi, I'm building a web app with nevow/twisted and I'm really impressed. I'm having a small problem with Formless though when trying to upload a file: here is my interface: class IAddDocument( formless.TypedInterface ): """Interface for Add Document form""" def addDocument( self , context = annotate.Context() , fdata = annotate.FileUpload( required = True ) ): pass addDocument = formless.autocallable( addDocument ) The form renders fine (I'm using a template pretty much based on the one in one of the tutorials except I've messed about with the table layout a bit) and lets me choose a file for upload - it also seems to upload the file. However when my method is called on my page class: def addDocument( self , context , fdata ): ... fdata is None. I've looked at the request from the context and the filename seems to be there but not the file data. Can anyone shed any light on this. Its a bit of a sticking point for me right now cheers mark ************************************************************************** Experience the British Library online at www.bl.uk Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook ************************************************************************* The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. *************************************************************************

2 1

Getting started using the twisted web server
by Dan Eloff Sept. 7, 2004

Sept. 7, 2004

My goal is to create a scalable web server for use by either a single individual on his own computer, or by thousands of people on a remote server. This server must be capable of serving up both files from the filesystem like .swf, .gif, .jpg, and .html and data produced dynamically by the same python process as the server is running in. In other words not your standard php/cgi setup where a script is executed when you browse to the file (http://localhost/myscript.php), but rather where a function from the running host process is called when a certain url is given (http://localhost/func/func-id). I can't think of a better solution to the problem than twisted, but I need help getting started. Is there any examples or anything more that I can learn from than the API docs? Thanks, -Dan

4 5

(no subject)
by Chaitan_Rogers＠bat.com Sept. 7, 2004

Sept. 7, 2004

Hello, I was wondering whether Nevow/Formless includes a) a multiselect 'Typed' class. b) if there is a way to convince the included Choice class to produce its output in the form: <select> <option value='foo'>Foo</option> <option value='bar'>Bar</option> </select> instead of: <select> <option value='0'>Foo</option> <option value='1'>Bar</option> </select>. I still haven't figured out how all these components fit together. Cheers, Chaitan ______________________________________________________________________ Confidentiality Notice: The information in this document and attachments is confidential and may also be legally privileged. It is intended only for the use of the named recipient. Internet communications are not secure and therefore British American Tobacco does not accept legal responsibility for the contents of this message. If you are not the intended recipient, please notify us immediately and then delete this document. Do not disclose the contents of this document to any other person, nor take any copies. Violation of this notice may be unlawful. ______________________________________________________________________

1 0

returning a formless form from render_foo
by Tim Stebbing Sept. 6, 2004

Sept. 6, 2004

gday all, Im using nevow 0.2.0, ive got a simple formless resource that works fine when I view it alone, but when I return it from a render_ method, I get nevow.compy.CannotAdapt: <redpanda.root.Index object at 0x4049796c> (type redpanda.root.Index) cannot be adapted to <class 'formless.iformless.IConfigurable'>. where redpanda.root.Index has: def render_foo(self, ctx, data): return FooForm() Why is it trying to adapt the Index resource? whats the proper way to include a form resource in a templates output? cheers, tjs

3 2

how to set charset of html page
by Benjamin Ferrari Sept. 1, 2004

Sept. 1, 2004

Hello, I just started with twisted, so I guess this is a very easy question: I run a twisted.web server with mktap: % mktap web --path /path/to/content % twistd -nf web.tap and then put a simple html page into the path folder: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body>...</body> unfortunately, browsers (tested with firefox 0.9.3 and IE6) completly ignore the <meta/> tag and detect the page as UTF-8 instead of iso-8859-1. with apache, I can set a default charset to use with AddDefaultCharset iso-8859-1 How can I do that with the twisted server ? Thanks for your help, Benjamin PS: I'm running twisted as a reverse proxy behind an apache2 server. Not sure if that matters.

2 1

Subclassing a subclass of rend.Page
by Patrick B. Day Sept. 1, 2004

Sept. 1, 2004

A quick question. I have a situation where I'm starting from a base html template, say 'template.html', which has some global elements which need rendering. So I do something like this: class Template (rend.Page): docFactory = rend.htmlfile('template.html') def render_global (self, context, data): """Fill in elements common to all pages.""" class GreetingsPage (Template): def render_contents (self, context, data): """Render contents area of page with greetings information.""" def render_sidebar (self, context, data): """Render sidebar area of page specific to greetings.""" When I try this approach though, nevow seems to make all it's rendering calls to Template and not GreetingsPage. What is the proper approach to doing what I'm trying to do? Thanks for your help. ============================ Patrick Day uf069(a)victoria.tc.ca

2 2

Re: [Twisted-web] Diagraming Twisted apps
by Sergio Trejo Sept. 1, 2004

Sept. 1, 2004

Clark, I just got around to trying out your suggestion of UML diagrams of my Twisted application (PyUmlGraph and graphviz). I have both applications working, but PyUmlGraph requires a running python application. I tried using PyUmlGraph with a .tac file that I had started as a twistd daemon. This .tac file contains code that instantiates a few Portals (and Realms tied to the Portals) for the purpose of running a Perspective Broker Server (listening on a specific port). PyUmlGraph seems limited because it only captures intantiated objects at run time (thus the python code that PyUmlGraph runs must have all of the objects of interest instantiated based on the moment that PyUmlGraph runs the code through the python interpreter). Thus, if you have a Twisted (PB Server) application running and TCP listening to a port (I.e., port 8000), sinces its waiting for asynchronous responses (such as from a PB Client connection and login), I don't know of any way to run PyUmlGraph in order to capture the objects that are instantiated by an asynchronous trigger. Maybe I'm missing something. Do you have any suggestions on how to use PyUmlGraph in this regard? Cheers, Serj >From: "Clark C. Evans" <cce(a)clarkevans.com> >Reply-To: "Discussion of twisted.web, Nevow,and Woven" ><twisted-web(a)twistedmatrix.com> >To: twisted-web(a)twistedmatrix.com >Subject: Re: [Twisted-web] Diagraming Twisted apps >Date: Sun, 22 Aug 2004 14:06:43 -0400 > >On Sun, Aug 22, 2004 at 10:51:12AM -0400, Sergio Trejo wrote: >| Has anyone tried using Dia? > >I use graphviz and a UML graphing tool based on its dot files. >http://www.zipcon.net/~adamf/software/PyUmlGraph/ >http://www.research.att.com/sw/tools/graphviz/ > >Clark > >_______________________________________________ >Twisted-web mailing list >Twisted-web(a)twistedmatrix.com >http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0