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?
We are working on a project that has to extract weather information from
an NMEA stream. There is a NMEAReceiver class, but it only extracts GPS
information - as expected, since the class is defined in t.p.gps.nmea.
We intend to add the NMEA-0183 messages necessary for my purposes. The
question is: should we just extend the NMEAReceiver? Weather information
is not exactly what one would expect in a class below t.p.gps...
On the other hand, it would be strange to create a different kind of
NMEAReceiver which knows how to handle the messages dealing with
Weiermayer Solutions GmbH | Abteistraße 12, A-4813 Altmünster
phone: +43 (0) 720 70 30 14 | fax: +43 (0) 7612 20 3 56
I am using a Perspective Broker to service requests from a client on the same machine ( Windows XP ). This works fine most of the time however occasionally I see strange behaviour. The client uses connectTCP and provides a timeout of 5 seconds. Logging indicates that the client attempts to make a connection to the server, server logging in the remote methods indicates that the method is not called. Also my error callback on the client is not invoked after the timeout period. Unfotunately this is part of a large system, sporadic behaviour and difficult to generate a test case for.
Also commonly requests a few seconds before and after the issue are handled correctly so the behaviour seems transient. We are using a older version ot twisted 8.x. Any pointers?
I am following "twisted in 60sec" series, but even the simple examples
are a bit unclear to me, especially w.r.t. url mapping. For example:
# assume the right imports...
isLeaf = True
def render_GET(self, request):
resource = MainPage()
factory = Site(resource)
I was expecting that accessing any other 'path' besides the main url
would cause 404, e.g. "http://localhost:8880/foo/bar", and I get the
same page instead.
I gather this is a consequence of the isLeaf setting set to be True,
because twisted.web stops as soon as it encounters MainPage in the
hierarchy and use that for rendering. Setting it to False seems to avoid
the page to be available at all. The solution I got instead is something
isLeaf = False
def render(self, request):
def getChild(self, path, request):
and adding new resources through putChild. Isn't there a more natural
way of doing things ?
Twisted 10.2.0, the third Twisted release of 2010, has emerged from the mysterious depths of Twisted Matrix Labs, as so many releases before it. Survivors of the release process - what few there were of them - have been heard to claim that this version is "awesome", "even more robust", "fun-sized" and "oven fresh".
Crossing several things that shouldn't ought to be, including the streams and the rubicon, I have assumed the triple responsibilities of feature author, project leader, *and* release manager for 10.2: with this dark and terrible power - a power which no man ought to wield alone - I have wrought a release which contains many exciting new features, including:
- A plug-in API for adding new types of endpoint descriptions. <http://tm.tl/4695>
- A new, simpler, substantially more robust CoreFoundation reactor. <http://tm.tl/1833>
- Improvements to the implementation of Deferred which should both improve performance
and fix certain runtime errors with long callback chains. <http://tm.tl/411>
- Deferred.setTimeout is (finally) gone. To quote the author of this change:
"A new era of peace has started." <http://tm.tl/1702>
- NetstringReceiver is substantially faster. <http://tm.tl/4378>
And, of course, nearly one hundred smaller bug fixes, documentation updates, and general improvements. See the NEWS file included in the release for more details.
Look upon our Twisted, ye mighty, and make your network applications event-driven: get it now, from:
... or simply install the 'Twisted' package from PyPI.
Many thanks to Christopher Armstrong, for his work on release-automation tools that made this possible; to Jonathan Lange, for thoroughly documenting the process and thereby making my ascent to the throne of release manager possible, and to Jean-Paul Calderone for his tireless maintenance of our build and test infrastructure as well as his help with the release.
Most of all, thanks to everyone who contributed a patch, reported a bug or reviewed a ticket for 10.2. Not including those already thanked, there are 41 of you, so it would be a bit tedious to go through everyone, but you know who you are and we absolutely couldn't do it without you! Thanks a ton!
Tahoe-LAFS uses Twisted extensively, and we try to contribute a few
patches back to Twisted itself when we can.
ANNOUNCING Tahoe, the Least-Authority File System, v1.8.1
The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.8.1 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:
Tahoe-LAFS is the first distributed storage system to offer
"provider-independent security" — meaning that not even the
operators of your storage servers can read or alter your data
without your consent. Here is the one-page explanation of its
unique security and fault-tolerance properties:
The previous stable release of Tahoe-LAFS was v1.8.0, which was
released September 23, 2010 .
v1.8.1 is a stable bugfix release correcting a number of minor
issues. It also includes a modest performance improvement in
downloading, and a fix for a security issue involving HTTP
proxies. See the NEWS file  for details.
WHAT IS IT GOOD FOR?
With Tahoe-LAFS, you distribute your filesystem across
multiple servers, and even if some of the servers fail or are
taken over by an attacker, the entire filesystem continues to
work correctly, and continues to preserve your privacy and
security. You can easily share specific files and directories
with other people.
In addition to the core storage system itself, volunteers
have built other projects on top of Tahoe-LAFS and have
integrated Tahoe-LAFS with existing systems, including
Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
more. See the Related Projects page on the wiki .
We believe that strong cryptography, Free and Open Source
Software, erasure coding, and principled engineering practices
make Tahoe-LAFS safer than RAID, removable drive, tape,
on-line backup or cloud storage.
This software is developed under test-driven development, and
there are no known bugs or security flaws which would
compromise confidentiality or data integrity under recommended
use. (For all important issues that we are currently aware of
please see the known_issues.rst file .)
This release is compatible with the version 1 series of
Tahoe-LAFS. Clients from this release can write files and
directories in the format used by clients of all versions back
to v1.0 (which was released March 25, 2008). Clients from this
release can read files and directories produced by clients of
all versions since v1.0. Servers from this release can serve
clients of all versions back to v1.0 and clients from this
release can use servers of all versions back to v1.0.
This is the twelfth release in the version 1 series. This
series of Tahoe-LAFS will be actively supported and maintained
for the forseeable future, and future versions of Tahoe-LAFS
will retain the ability to read and write files compatible
with this series.
You may use this package under the GNU General Public License,
version 2 or, at your option, any later version. See the file
"COPYING.GPL"  for the terms of the GNU General Public
License, version 2.
You may use this package under the Transitive Grace Period
Public Licence, version 1 or, at your option, any later
version. (The Transitive Grace Period Public Licence has
requirements similar to the GPL except that it allows you to
delay for up to twelve months after you redistribute a derived
work before releasing the source code of your derived work.)
See the file "COPYING.TGPPL.html"  for the terms of the
Transitive Grace Period Public Licence, version 1.
(You may choose to use this package under the terms of either
licence, at your option.)
Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris,
*BSD, and probably most other systems. Start with
HACKING AND COMMUNITY
Please join us on the mailing list . Patches are gratefully
accepted -- the RoadMap page  shows the next improvements
that we plan to make and CREDITS  lists the names of people
who've contributed to the project. The Dev page  contains
resources for hackers.
Tahoe-LAFS was originally developed by Allmydata, Inc., a
provider of commercial backup services. After discontinuing
funding of Tahoe-LAFS R&D in early 2009, they continued
to provide servers, bandwidth, small personal gifts as tokens
of appreciation, and bug reports.
Google, Inc. sponsored Tahoe-LAFS development as part of the
Google Summer of Code 2010. They awarded four sponsorships to
students from around the world to hack on Tahoe-LAFS that
Thank you to Allmydata and Google for their generous and
If you can find a security flaw in Tahoe-LAFS which is serious
enough that we feel compelled to warn our users and issue a fix,
then we will award you with a customized t-shirts with your
exploit printed on it and add you to the "Hack Tahoe-LAFS Hall
Of Fame" .
This is the sixth release of Tahoe-LAFS to be created solely
as a labor of love by volunteers. Thank you very much to the
team of "hackers in the public interest" who make Tahoe-LAFS
David-Sarah Hopwood and Zooko Wilcox-O'Hearn
on behalf of the Tahoe-LAFS team
November 28, 2010
Rainhill, Merseyside, UK and Boulder, Colorado, USA