On Jun 22, 2012, at 2:52 PM, Peter Westlake <peter.westlake(a)pobox.com> wrote:
> On Thu, Jun 21, 2012, at 10:16, Glyph wrote:
>> Le Jun 21, 2012 à 6:52 AM, Peter Westlake <peter.westlake(a)pobox.com> a
>> écrit :
>>> How fast is rendering in nevow? I have a page which is mostly a large
>>> table with a couple of hundred rows, each containing a form. The
>>> generated HTML is about 500 KB. Leaving aside the question of whether
>>> this is a good design or not, how long would you expect it to take? I'm
>>> interested specifically in what happens between the end of beforeRender
>>> and the request being completed. It takes about a minute and a quarter.
>>> Is that normal, or is there a delay in my code that I haven't found yet?
>> What does your profiler tell you?
> There's a profiler? There's a profiler! There it is,
> right up there at the top of the man page! Thank you!
Not only is there a profiler, there's benchmarks!
Maybe you could add one for twisted.web.template rendering speed?
> P.S. sorry, this was really meant to go to the twisted-web list.
> I suspect a last-minute substitution by my email client.
Thanks for the thought, at least. Cross-posted.
There were a lot discussions regarding Websockets few months (years?) back, before the RFC6455 was released and the hybi group defining the protocol was in pretty messy state.
Now this technology is stable and coming mainstream with almost all browsers supporting it, so i think it's time to reopen the question for Twisted.
There are many forks on Github from the original work of rlotun called txWebSocket.
My branch may be the most advanced ( https://github.com/aprilmay/txWebSocket ).
It works quite well for my purpose until now, even if it can surely be improved.
It has both server and client, trial tests, basic support for extensions (eg compression and multiplexing are on the way from the hybi group) and i hope is efficient enough for most uses.
There is also a project called Autobahn but it is not integrated with twisted.web (so one cannot serve standard HTTP and websockets from the same service out of the box) and was designed first to be a test suite for the development of the protocol.
What are the opinions from the core team and other people in this list on this?
I'm new to Twisted and it looks like a good way to add a web server to my
existing project. I am successfully following the example at
display the directories with the default file listing code.
Now I want to modify that default behavior for directory listing to:
- filter out/exclude certain kinds of files (e.g., by the extension), and
- add a few elements to the HTML page displayed.
I've read the code of static.py, and see that the the DirectoryLister class
seems to govern this. I believe I need to make a subslass, but I'm not a
strong Python programmer, so the minor variations I tried kept running
amiss of the class hierarchy, etc.
Could someone give me an outline of the method declarations that are needed
to get the behavior above? Many thanks.
Hanover, NH USA
Given that twisted tutorials and other written materials show examples of derived classes for Protocol, HTTP Request etc., is there a good reason for many classes (almost all I suspect) (e.g. 'class Request' , 'class BaseProtocol', 'class _PauseableMixin', etc.) to be old style classes as opposed to a new style python classes?
Given that newer versions of twisted (and user apps) run on newer versions of python, I initially (a few years ago) tried to call the base class using super(), but was surprised to find twisted implements using old style classes.
New style classes make it easy to call a base class method (by using super). Would the MRO in new style classes make it better or worse? However, nothing wrong with old style classes, esp. if twisted depends on the depth-first MRO of old style classes.
Can someone clarify whether use of old style classes is intentional (e.g. due to MRO)?
I realize it does become an instance variable as soon as it is assigned a value, hence I was perplexed as to why it did not have the intended effect. Thanks for pointing out that the name is mangled. That clarifies it! I forgot about name mangling (although I did realize attrs starting with '_' are intended to be implementation detail private).
In any case, I do not replicate the logic of allContentReceived () anymore. Instead, I just call the base class method in my derived class.
I had to have a derived class because the following line throws an exception:
req = self.requests[-1]
because of my special handing of the request connection (the req is gone by the time allContentReceived() gets called). What is my special handling? I tie up the request using producer/consumer to some other resource before the entire content is received.
So for now I am fine with:
except Exception, e:
Speaking of derived classes, ... I will pose a related question on a new thread ...
Should http.py :: HTTPChannel.__first_line be an instance attribute instead of a class attribute?
I have a custom scenario where I sub-classed HTTPChannel for my sub-classed HTTPFactory. In the DerivedHTTPChannel class I overrode the allContentReceived() method.
I recently enabled persistent connections, but setting self.__first_line = 1 in the DerivedHTTPChannel was ineffective, and the first line of the next request threw an exception when it got parsed as an http header. Similar question "probably" apply to other class attributes.
Should such attributes be instance attributes instead of class attributes? Or is it anticipated that any class who derives from HTTPChannel should override almost all the methods of the base class?