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
I have an xml file in my application,
I have created an element using
Example goes like this.........
and i appeneded it by using append() method.
But how i can reflect this change to my xml file?
and one more thing is i want to create element with some other parameters....
<abc m=" " n=" ">
and i have m and n values as strings with me.
can anybody help me to create this element and write it to the existing xml file
as a child of an existing element?
Thanks in advance..
Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php
On 18 May 2004, the following message was posted to this mailinglist:
Jp Calderone exarkun at divmod.com wrote:
>Daniel Newton wrote:
> I have a simple XML-PRC server similar to the example below:
> from twisted.web import xmlrpc, server
> class Example(xmlrpc.XMLRPC):
> """An example object to be published."""
> def xmlrpc_add(self, a, b):
> """Return sum of arguments."""
> return a + b
> if __name__ == '__main__':
> from twisted.internet import reactor
> r = Example()
> reactor.listenTCP(7080, server.Site(r))
> I want to be able to get the address of the client that calls the
> method can anyone help me with this?
This solution didn't work because 'transport' isn't a property of the
I'm currently in the process of changing from a customized
SimpleXMLRPCServer to a twisted XMLRPC server solution and I need to
insert the client IP into the attributes passed to the called xmlrpc
method. Anyone who knows the answer and is willing to share the info?
Thanks for the hint, it took me a while to make it work but it does do
the job very well.
For future reference to the thread readers, the bytes to skip are the
first 10 of the first set of data received by the protocol.
I'm using LDAP to authenticate users, and when I give it an empty
password, it appears to succeed! Can anyone see what I'm doing wrong?
I've added comments by the log messages that appear in the output.
from twisted.internet import reactor, defer
from ldaptor.protocols.ldap import ldapclient, ldapsyntax,
from ldaptor.protocols import pureldap as L
def __init__(self, base_dn, hostname=None, attr='uid', bind_dn='',
self.hostname = hostname
self.base_dn = base_dn
self.attr = attr
self.bind_dn = bind_dn
self.bind_pw = bind_pw
self.filter = filter
self.cli = None
def authenticate(self, username, password):
if not password:
log.info('Empty password!!!!') #######
log.debug('Attempting to login as', username)
c = ldapconnector.LDAPClientCreator(reactor,
self.client = yield c.connect(self.base_dn)
entries = 
base = ldapsyntax.LDAPEntry(self.client, self.base_dn)
attributes = (self.attr,), # No need to read the whole
n_entries = len(entries)
if n_entries == 0:
log.debug('Failed login for %s: no search results' %
raise Exception('No search results!')
elif n_entries > 1:
log.debug('Failed login as %s: %d search results for unique
entry!' % (username, n_entries))
raise Exception('%d search results for unique entry!' %
# The password matches if we can bind as this DN with it.
if not password:
user_entry = yield entries.bind(password)
if not password:
log.info('Succeeded with an empty password!')
log.info('Failed login for %s: invalid credentials' %
except Exception, e:
log.rep(e, 'Error while binding with user password')
I have written a small utility function to replace
"twisted.web.client.getPage", to be able to read the response header.
I have to say that the ever improving documentation made it quite easy for
me to do it using the new twisted.web.client.Agent, so well done to all!
Since my wrapper works quite well, I decided to add gzip response support,
as it's another feature lacking from the original getPage. Again, it was
quite simple and it looks it works quite well, in proof of concept scenario.
Then it came my dilemma. What I'm doing now is a synchronous decompression
as shown below:
compressedstream = StringIO.StringIO(inzip)
gzipper = gzip.GzipFile(fileobj=compressedstream)
_data = gzipper.read()
This works quite well, but I wanted to add support for arbitrary large
compressed responses, and I wanted to ask your opinion on the best approach
-a separate thread? it has it's limit, as it's not scaling well at all, but,
in the possible scenario of a getPage usege shouldn't be a big issue (i.e.
not many concurrent calls)
-a Producer/consumer? That sounded like the modern twisted way of doing it,
but I didn't manage to be able to implement it properly, as I could create a
proper "consumer" class by looking to the example in the documentation...
I found this and seemed a potential way of doing it, with may be the use
of inline generators?
But then, I thought, is it a too complex approach for a simple problem?
I guess that decompressing data in twisted should be a fairly common task,
but I have not found a sample that looked like the "best" way for doing it,
so... here is this email
Thanks for you help, and I'll be happy to post the final code for future
reference if anyone is interested
The code is in attachment.
I run it on Debian/Linux, twisted 10.0.0
When you run it on a terminal, it works by prefixing the data you enter with "dataReceived: "
and outputting that back to terminal.
o: dataReceived: 'blabla
o: readConnectionLost(input is done)
The same happens if you redirect output to a pipe (no matter if it a named FIFO or an anonymous pipe).
But if you redirect output to a file or to a /dev/null, this happens:
$ ./program.py > /dev/null
<a short pause, no input>
o: StdioProtocol.connectionLost('[Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
But I expected it to work the same way, regardless of redirections.
I haven't traced the source of that Failure, so just asking, whether that behavior is
known, or maybe intended?
Or, perhaps, I do something incorrectly?
Well, right now I'm using the workaround with /bin/cat:
$ ./program.py > >(cat > file)
or with an extra shell process:
$ ./program.py | cat > file