hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
Attached is a short patch to add a --resource option to "mktap web",
here is the --help for it:
-r, --resource= <class> is the name (including module) of a subclass of
twisted.web.resource.Resource to publish.
So you can have any subclass of t.w.r.Resource be the 'root' of your
I have also been working on a few other things:
- an async Pytho-only PostgreSQL interface (not t.e.adbapi
compatible, since I am not usre I like it's interface and need
to play a bit before I figure out how I would like an async
SQL-database interface to behave.)
- a SQLResultWidget, very dull right now but I will probably hack
some BoboDTML support into it.
Sune Kirkeby | /* we're still looking for the end of the
| * server's header ... (does that make header
| * parsing an "out of body experience" ? */
| -- jcc.c in junkex source-code
Anyone who has programmed in depth with Twisted probably know about
arm()ing deferreds by now. Nobody has complained as loudly as I thought
they would, so I'm not sure if this is really that big of a problem, but
I'm questioning my original design decisions regarding .arm().
Originally, I wanted it to be easily determineable whether your callback
would be called before your stack had been escaped; so the system you
returned your Deferred to would .arm() it afterwards. However, this
creates lots of weird, confusing corners for callbacks to get lost in,
and I have yet to see a situation where it actually matters whether your
current stack frame is escaped before the callback happens.
I would like to propose that we create an experimental mode where .arm()
be made to do nothing (for backwards compatibility), and that
.callback() call whatever callbacks are available immediately; and
.addCallbacks() (and friends) will immediately call any pending
callbacks. If after an extended period of testing it is discovered that
there are no bugs created with this approach, we should remove .arm()
I'd like some feedback on this, though. Does anyone else think that
callbacks sometimes happening and sometimes not when .addCallbacks() is
called makes a difference? Anyone feel strongly that .arm() is
confusing and unnecessary?
| <`'> | Glyph Lefkowitz: Travelling Sorcerer |
| < _/ > | Lead Developer, the Twisted project |
| < ___/ > | http://www.twistedmatrix.com |
Given some of the chats I've had with Glyph regarding bug tracking,
customer support, and project management in Twisted, here's a nice
overview article that provides some concrete definitions and feature
descriptions for each. Note the "Workflow Management" paragraph where
the author claims that the above mentioned systems are instances of
Workflow Management and a system built around workflow management
abstractions could be 'trivially' used to develop the others.
Looking at the numerous examples of partial implementations of these
various systems out there, it seems that it is easy to start one of
these projects, but hard to get it to the point where it is actually
useful (and I'm specifically looking at project management here).
Apparently there was a project manager called Xen for Zope, but it seems
But here are two interesting bits of code that could be incorporated
into a Twisted-based project manager -- PyGantt, which take an
XML-formatted project description and generates an HTML Gantt chart; and
an O'Reilly article that describes something similar with Piddle.
PyGantt is neat because it could be modified to generate hyperlinked
project task titles that would go to a task description dialog (or
page). Dates could also be hyperlinked for editing. The XML part could
be factored out into import/export, and the project description could be
instead accessed from project-tree and task-node instances in Twisted.
Having a way to represent "user stories" and "use cases" as task nodes
would be cool. Then Roark could (ahem, when I get time to help Matt
work on it) be used to create and edit use cases and other modeling
entities and the task manager could be used to schedule and track
progress on them.
Apparently, HTTP proxies have a command CONNECT, that lets you open a
TCP/IP connection to an arbitrary host and port. This is intended for
HTTPS. Now, most proxies probably limit this to 443 only, HTTPS port.
So, presumably all those clients like ICQ that let you run over HTTP
proxy - they use this, and have a ICQ server running on port 443. Thus
allowing people to use it behind corporate firewalls.
So, we need a HTTPProxy transport that will do this automatically for
clients, along with a SOCKSv4 transport and eventually a SOCKSv5 transport.
proxy = HTTPProxier("proxy.isp.net", 8080)
proxy.clientTCP("www.example.com", 443, myProtocolInstance)
# cool, huh?
Attached you'll find three short patches, two against
t.w.widgets.RenderSession and one against t.p.http.Request.
The first patch makes RenderSession unicode-agnostic (i.e. makes it
treat string and unicode object alike). The second one makes
t.p.http.Request aware of unicode, to the extent that it will
correctly handle unicode strings with all ordinals < 128 (by simply
The last patch makes RenderSession.callback return the result it was
passed, so that later callbacks made by the given Deferred also
benefit from this knowledge. It had completely escaped me that
Deferred._runCallbacks acts like a folding operation, last I poked
around in the code.
Sune Kirkeby | % cat /usr/include/sys/errno.h
| #define EPERM 1 /* Operation not permitted */
| #define EMACS 666 /* Editor Too Large */
In a fit of God-how-I-hate-all-other-template-languages I decided to
take another look at Zopes PageTemplates (TAL, METAL and friends).
I ended up liking the beast so much I decided to start porting it to
Twisted, which resulted in the attached t.w.tal module. It is still
very incomplete, and most likely also very buggy. But, in the
interest of feedback I post it here.
It dislikes it when I reuse deferreds (t.w.w.RenderSession becomes
very confused and claims to be "rendering unknown" for all but the
Other than that the only problem I have had so far was that I had to
remove a str'ing in the TAL-engine.
Sune Kirkeby | 5 out of 4 people have trouble with fractions.
If you do reactor.listenTCP on a factory, startFactory and stopFactory are
never called. I therefore suggest that we add methods doStart and doStop to
protocol.Factory, like so, and have them called in listenTCP/UDP/SSL, and
remove calls to start/stopFactory from app.Appliecation:
running = 0
if not self.running:
self.running = 1
self.running = 0
This ensures the start/stopFactory methods will only be called once, even if
the factory is added to multiple Ports, and makes sure that they get called
even if the factory is added to the reactor directly.
LDAP support has been removed from the main Twisted tree.
For the future, please refer to
- the main application for now is a web-based editor/browser
for an LDAP directory.