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
Now you can configure your TAP files through the web!
coil [--new=<application name>] <tap file>
-p, --port= [default: 9080]
For example, to configure a TAP generated by mktap:
$ mktap web
$ coil web.tap
(now point browser at http://localhost:9080)
Or to create a new TAP:
$ coil --new=myapp new.tap
(now point browser at http://localhost:9080)
== Make ports visible ==
Currently, tcp/udp/ssl are treated as collections of protocol factories. I
am going to change this to collections of Ports, so that you can configure
interfaces to listen on, context factories for SSL, etc. The protocol
factory will just be another attribute.
This should have no effect on people who are coiling their apps.
== Make old TAPs work ==
The refactor broke old taps - they can no longer be loaded since they refer
to non-existence classes in twisted.internet.app.
This can probably be easily solved (make a dummy PortsCollection class and
delete the attributes of the loaded application that refer to it.)
My name is Joan Torres, I'm working in Port of Barcelona (spain), and
I'm interested in learning more about how to use Twisted.
I've two Python applications running on a Unix platform, both applications
return a file as a result, and I want to write a server for them.
The server should do the following things:
- Execute Application1 every 10 minutes
- Run Aplication1 on demand.
- Keep the last file returned by application 1
- Execute Aplication2 on demand.
There would be three different types of clients (windows platform):
* Client type 1: get the latest file returned by applition1
* Client type 2: run application1 and get the returned file
* Client type 3: run application2 and get the returned file
The estimated amount of connections at a time could be:
-clients type 1: 100
-clients type 2: 2-3
-clients type 3: 2-3
Could anyone give me some light on it?
Each time I checkin a file, the CVS process then gets stuck (if I check-in
two files it gets stuck after the first). I'm not sure why -- perhaps this
is relevant (as pointed out by Tv):
Or perhaps it's some other issue.
This bug needs an answer from someone with unix expertise:
I suggest getting rid of SIGCHLD handler, and having t.i.process.Process
instances keep track of the pid of their process, and pass it to reapProcess
so it only waitpid()s on a specific pid, and not all of them.
I will add a test case which will test for this bug.
Background: COIL is a configuration system for Twisted, allowing you to
manage and configure your server via the web, developed by glyph. To test it
$ mktap coil
$ twistd -n -f coil.tap
And point your browser at http://localhost:9080
In CVS, the coil system has been refactored, and now resides in
twisted.coil. I feel that at this point it is now usable for configuring
real apps. Real world use will help us find missing requirements and find
issues and bugs. Examples of how to use it can be found in twisted.coil.plugins.
Things that should really be coiled include cred, to the point that you can
use coil to administrate users for manhole. t.mail is another candidate, and
of course any servers based on twisted.
If you are not using CVS Twisted, do not use coil - the interfaces have all
been changed. You can still play around with it however, since it does work
in the released code as well.
I did some heavy refactoring on my python MSN code this weekend. If anyone
is interested in taking a sneak preview at the code (and comment on the
API, etc), feel free to download some code at:
There's no docs (except for an msn protocol description), but there
are two sample programs included: 'client.py' which is a very simple
gtk/glade interface, and 'msntxttest.py' which basically echoes back
anything that's sent to the client.
The code is at this moment still very incomplete, and still needs loads
of work, but you should be able to login using an existing msn
handle/password, and send/receive messages.
At this moment, I've only tested with everybuddy at the other end of
the session - it may be that MS's msn client sends more noise that confuses
the clients - I'll test this later.
Patches, remarks, suggestions are welcome.
Ivo (VladDrac @ OPN)
Drs. I.R. van der Wijk -=-
Brouwersgracht 132 Amaze Internet Services V.O.F.
1013 HA Amsterdam, NL -=-
Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase
Fax: +31-20-4688337 Network Solutions
Web: http://www.amaze.nl/ Consultancy
Email: ivo(a)amaze.nl -=-
On Mon, 2002-03-25 at 05:34, itamarst CVS wrote:
> If a configurable class is not collection, coil's web interface will
> check if the Configurator class is a collection, allowing us to have
> Configurators that act as collections.
> A remaining issue is twisted.web.vhost, and other similar cases, where
> both the Configurator and the configurable class should really be
IMHO, the way this should work is: check the Configurator first. It is
the authority on collection-hood, as it were. :-). If the
*configurator* is not a collection, then check the configurable; this
strikes me as a less likely case... in fact, it seems weird to
introspect on the configurable at all at this point, since it isn't the
Does that make sense?