Mailman 3 April 2009 - Twisted

[Twisted-Python] Ldaptor for a simple python LDAP server
by Alex Davies April 15, 2009

April 15, 2009

Hi, I'm looking to write a very simple LDAP server in Python. I want to hard code the few attributes that I have, and make them available to clients. I am not the worlds most able programmer, but have looked at the code, documentation and talks about Ldaptor and it seems that this can do what I need - but I can't find any examples anywhere! Is there a simple example that shows me what is needed to build a super-simple LDAP server in Python? Any pointers from the more able would be much appreciated! Many thanks, Alex

1 0

[Twisted-Python] ANNOUNCING Tahoe-LAFS v1.4
by zooko April 14, 2009

April 14, 2009

ANNOUNCING Tahoe, the Least-Authority Filesystem, v1.4 The allmydata.org team is pleased to announce the release of version 1.4.1 of "Tahoe", the Lightweight-Authorization Filesystem. This is the first release of Tahoe-LAFS which was created solely as a labor of love by volunteers -- it is no longer funded by allmydata.com (see [1] for details). Tahoe-LAFS is a secure, decentralized, fault-tolerant cloud storage system. All of the source code is publicly available under Free Software, Open Source licences. This filesystem is distributed over multiple servers in such a way the filesystem continues to operate correctly even when some of the servers are unavailable, malfunctioning, or malicious. Here is the one-page explanation of Tahoe's unique security and fault-tolerance properties: http://allmydata.org/source/tahoe/trunk/docs/about.html This is the successor to Tahoe-LAFS v1.3, which was released February 13, 2009 [2]. This is a major new release, adding garbage collection, improved diagnostics and error-reporting, and fixing a critical performance problem when downloading large (many GB) files. See the NEWS file [3] and the known_issues.txt file [4] for more information. Besides the Tahoe core, a crop of related projects have sprung up, including frontends for Windows and Macintosh, two front-ends written in JavaScript, a Ruby interface, a plugin for duplicity, a plugin for TiddlyWiki, a new backup tool named "GridBackup", CIFS/SMB integration, an iPhone app, and three incomplete frontends for FUSE. See the Related Projects page on the wiki: [5]. COMPATIBILITY Tahoe v1.4 is fully compatible with the version 1 series of Tahoe. Files written by v1.4 clients can be read by clients of all versions back to v1.0. v1.4 clients can read files produced by clients of all versions since v1.0. v1.4 servers can serve clients of all versions back to v1.0 and v1.4 clients can use servers of all versions back to v1.0. This is the fifth release in the version 1 series. The version 1 series of Tahoe will be actively supported and maintained for the forseeable future, and future versions of Tahoe will retain the ability to read files and directories produced by Tahoe v1 for the forseeable future. The version 1 branch of Tahoe is the basis of the consumer backup product from Allmydata, Inc. -- http://allmydata.com . WHAT IS IT GOOD FOR? With Tahoe, you can distribute your filesystem across a set of servers, such that if some of them fail or even turn out to be malicious, the entire filesystem continues to be available. You can share your files with other users, using a simple and flexible access control scheme. Because this software is new, we do not categorically recommend it as the sole repository of data which is extremely confidential or precious. However, we believe that erasure coding, strong encryption, Free/Open Source Software and careful engineering make Tahoe safer than common alternatives, such as RAID, removable drive, tape, "on-line storage" or "Cloud storage" systems. This software comes with extensive tests, and there are no known security flaws which would compromise confidentiality or data integrity. (For all currently known issues please see the known_issues.txt file [3].) This release of Tahoe is suitable for the "friendnet" use case [6] -- it is easy to create a filesystem spread over the computers of you and your friends so that you can share disk space and files. LICENCE 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" [7] 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 wait 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" [8] 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.) INSTALLATION Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris, and probably most other systems. Start with "docs/install.html" [9]. HACKING AND COMMUNITY Please join us on the mailing list [10]. Patches are gratefully accepted -- the RoadMap page [11] shows the next improvements that we plan to make and CREDITS [12] lists the names of people who've contributed to the project. The wiki Dev page [13] contains resources for hackers. SPONSORSHIP Tahoe was originally developed thanks to the sponsorship of Allmydata, Inc. [14], a provider of commercial backup services. Allmydata, Inc. created the Tahoe project, and contributed hardware, software, ideas, bug reports, suggestions, demands, and money (employing several Tahoe hackers and instructing them to spend part of their work time on this Free Software project). Also they awarded customized t-shirts to hackers who find security flaws in Tahoe (see http://hacktahoe.org ). After discontinuing funding of Tahoe R&D in early 2009, Allmydata, Inc. has continued to provide servers, co-lo space and bandwidth to the open source project. Thank you to Allmydata, Inc. for their generous and public-spirited support. Zooko Wilcox-O'Hearn on behalf of the allmydata.org team Special acknowledgment goes to Brian Warner, whose superb engineering skills and dedication are primarily responsible for the Tahoe implementation, and significantly responsible for the Tahoe design as well, not to mention most of the docs and tests and many other things besides. April 13, 2009 Boulder, Colorado, USA [1] http://allmydata.org/pipermail/tahoe-dev/2009-March/001461.html [2] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=3620 [3] http://allmydata.org/trac/tahoe/browser/NEWS?rev=3835 [4] http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt [5] http://allmydata.org/trac/tahoe/wiki/RelatedProjects [6] http://allmydata.org/trac/tahoe/wiki/UseCases [7] http://allmydata.org/trac/tahoe/browser/COPYING.GPL [8] http://allmydata.org/source/tahoe/trunk/COPYING.TGPPL.html [9] http://allmydata.org/source/tahoe/trunk/docs/install.html [10] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev [11] http://allmydata.org/trac/tahoe/roadmap [12] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=3758 [13] http://allmydata.org/trac/tahoe/wiki/Dev [14] http://allmydata.com --- Tahoe, the Least-Authority Filesystem -- http://allmydata.org store your data: $10/month -- http://allmydata.com/?tracking=zsig I am available for work -- http://zooko.com/résumé.html

1 0

[Twisted-Python] Basic factory question
by Ted Pederson April 13, 2009

April 13, 2009

Coming from C++ to python/twisted. Looking at samples, created a simple server and want to create a tester file that will create many clients to connect to and exercise my server. All very nice and easy and like this a lot so far. The one thing that looks strange to me is that the samples instantiate a ClientFactory to then connect to the server via reactor.connectTCP(). I copied this pattern, worried that a factory would be created for every one of my clients, and this is indeed what happened. Isn't the point of a factory to generate all of the clients? I'd like to keep some aggregate info in 1 factory, and have the factory contain the dbpools, etc.. How to do this?

2 1

[Twisted-Python] Documentation overviews
by Cary Hull April 12, 2009

April 12, 2009

Hi folks, One of the goals for the Pycon sprint was to develop user oriented overviews for existing documentation. These would ideally guide users through everything they would need to read in order to accomplish a desired goal with Twisted. I've formulated the following 'track' suggestions based on a conversation in the sprint room a few nights ago. Feedback would be greatly appreciated. --- Overviews # The basics of event driven applications (beginner) # No hand holding, just the facts (advanced, already familiar with concepts involved) # Testing Twisted applications # Driving processes (interactively or otherwise) # Custom protocols # When it makes sense to use threads # Persisting application data (Would cover various options including Axiom) # Task scheduling (Would cover various options including Axiom) # Web clients # Web applications using just Twisted # Web applications using WSGI (Maybe show how to run Django) # Mail clients # Mail servers # SSH clients # SSH servers # XMPP (Jabber) clients # XMPP (Jabber) servers # Multiple servers in a single application # GUI applications (non web) # Networked video games

4 6

[Twisted-Python] adapt from more than one interface
by Esteve Fernandez April 12, 2009

April 12, 2009

Hi all. I have a bunch of services, which implement a set of interfaces, and I use a bunch of adapters to turn them into factories, making those services protocol-independent. The interface/adapter stuff works great and I'm able to expose those services to several protocols, without changing a single line in them. However, some of the protocols need some extra information to be passed, so I have to do this: factory = IFooFactory(myService) factory.bar = "some value" it works, but I'd rather use this: factory = IFooFactory(myService, configurationObject) which would take a second argument, an object implementing another interface (e.g. IConfigurationDescriptor), containing all the necessary information for that adapter. I don't want to put that information in the service, as it's only useful to the protocol and would tie the service to a particular protocol. In order to implement this, registerAdapter would have to be able to take a tuple of interfaces, like this: components.registerAdapter( AdaptToFactory, (IFooService, IConfigurationDescriptor), IFooFactory) would that feature make sense? If so, I'll file an issue right now :-) Cheers.

3 6

Re: [Twisted-Python] Giving inlineCallbacks-wrapped functions access to the deferred their wrapper will return
by Terry Jones April 12, 2009

April 12, 2009

>>>>> "glyph" == glyph <glyph(a)divmod.com> writes: glyph> When I write functions that take a Deferred I typically have them glyph> return a Deferred as well, to avoid this, and other syntactic glyph> nuisances. Would you consider the following more elegant? Yes. And thanks for the rule of thumb. In any case, I realized that my original idea wont work. _inlineCallbacks returns the deferred to the caller of the wrapped function early. The caller could add callbacks to it before the wrapped function does, which makes the whole idea unworkable. Terry

1 0

[Twisted-Python] Weekly Bug Summary
by exarkun＠twistedmatrix.com April 11, 2009

April 11, 2009

1 0

[Twisted-Python] Giving inlineCallbacks-wrapped functions access to the deferred their wrapper will return
by Terry Jones April 11, 2009

April 11, 2009

This will probably fall into the too-weird or too-infrequent to be worth implementing category, but I think it's worth mentioning. (BTW, none of the following code has been run.) When you write a normal function that returns a deferred, it (of course) has access to the deferred it's going to return: def func(): d = defer.Deferred() d.addCallback(...).addErrback(...) callSomethingElse(d) return d Apart from operating on the deferred itself, func can pass the deferred to some other function that might add more callbacks (as in the call to callSomethingElse). That's all very nice and convenient. But if I write this: @defer.inlineCallbacks def func(): # do some stuff to calculate a result. defer.returnValue(result) func never has its hands on the deferred that will be returned (by _inlineCallbacks) to the caller of its wrapper. I can get around this in ways that are less elegant: @defer.inlineCallbacks def func(): # do some stuff d = defer.Deferred() callSomethingElse(d) d.callback(result) newResult = yield d defer.returnValue(newResult) But I don't really like doing it that way: it's a slightly different coding style, it's much more manual, the above is just one simple example - actual usage could be more involved, and it doesn't feel as natural as the kind of code I can write when I'm not using inlineCallbacks. A way around this (which maybe will generate howls of protest) would be to have _inlineCallbacks do something this: def unwindGenerator(*args, **kwargs): assert '_inlineCallbacksDeferred' not in kwargs d = Deferred() return _inlineCallbacks(None, f(*args, **kwargs, _inlineCallbacksDeferred=d), d) return mergeFunctionMetadata(f, unwindGenerator) While I don't like this implementation much, it does manage to simply put the deferred that _inlineCallbacks will eventually return, into the hands of f (i.e., func above). func can then pass the deferred around, add callbacks to it etc. exactly as a normal (non-inlineCallbacks) function would. Maybe there's a cleaner way to implement this? I ran into this asymmetry today, when I wanted a function to pass its deferred off to another function but realized that because mine was an inlineCallbacks-decorated function I couldn't do it in the same way I would otherwise. Comments? Terry

2 1

[Twisted-Python] Plugin startup and shutdown actions
by luper rouch April 11, 2009

April 11, 2009

I would like to port my Application API based services to the twistd plugin interface, to be able to retrieve command line options. In the existing services, I reimplemented t.a.s.MultiService startService() and stopService() to do some actions at startup and shutdown. How can I do this in a plugin ? -- Lup

4 7

Re: [Twisted-Python] Plugin startup and shutdown actions
by Terry Jones April 11, 2009

April 11, 2009

Hi Luper >>>>> "luper" == luper rouch <luper.rouch(a)gmail.com> writes: luper> I have a last question, I put my plugins in a 'twisted/plugins' luper> subfolder of my project, and running them from the command line luper> works fine. How can I invoke them in unit tests (I need to be able luper> to start and stop them), since the plugin files are not in a luper> package? I suspect some will answer "Uh, you probably shouldn't be doing that"... But something like this will work: from twisted.plugin import getPlugins from twisted.application.service import IServiceMaker def getPlugin(name): for plugin in getPlugins(IServiceMaker): if hasattr(plugin, 'tapname'): if plugin.tapname == name: return plugin return None Terry

1 0