Mailman 3 February 2002 - Twisted

[Twisted-Python] perspective introspection
by Sean Riley Feb. 11, 2002

Feb. 11, 2002

other remote object APIs such as COM and CORBA have ways of asking a remote object for it's published interface. SOAP also has this with WSDL (http://www.w3.org/TR/wsdl). implementing a way for pb perspectives to tell consumers about their interface seemed like it would be a trivial undertaking - and it was: (for twisted.spread.pb): from twisted.python import reflect def perspective_getInterface(self): """Retrieve the set of perspective methods for this perspective. This allows client to retrieve the "published" external interface for this perspective/service. the result is returned in a dictionary with the keys being the names of the methods for the client to call, and the values a tuple of the names of the arguments to each method. """ dict = {} reflect.addMethodNamesToDict(self.__class__, dict, "perspective_") del dict["getInterface"] # remove the perspective_interface method (THIS method) # populate args for k in dict.keys(): func = self.__class__.__dict__["perspective_%s"%k] l = func.func_code.co_varnames[1:] dict[k] = l return dict it would probably even be possible to wrap this up into WSDL if we wanted to, for further "enterprise" compatibility... it isn't possible for clients to do this introspection on their own as they only have a RemoteReference to the perspective object. does this create any security holes? is a bad idea for any other reason? ---- "If it's not running programs or fusing atoms, it's just bending space.", Ken Macleod "That's it, I'm outta here.", Homer Simpson's Brain Sean Riley sean(a)ninjaneering.com

4 4

[Twisted-Python] Re: [Twisted-commits] CVS: Twisted ChangeLog,1.13,1.14
by Glyph Lefkowitz Feb. 11, 2002

Feb. 11, 2002

For those of you who do not subscribe, this is a message in response to a CVS commit. If you're interested in getting CVS commit messages, email me privately. On Mon, 2002-02-11 at 16:02, Chris Armstrong wrote: > Update of /cvs/Twisted > In directory zaibach:/tmp/cvs-serv21198 > > Modified Files: > ChangeLog > Log Message: > updated ChangeLog to reflect stuff on twisted-commits. IMHO this is far too fine-grained. Especially something like: > + * twisted/eco/eco.py: Reverted evaluator state back to functional-ness > + :) And added functions (anonymous and global), and broke various > + interfaces Not to mention the fact that the evaluator is hardly functional, even though it uses functions :) In general, NOTHING that gets changed in CVS and then gets changed *back* before the release ought to be documented in ChangeLog. This is confusing enough as is. -- "Cannot stand to be one of many -- I'm not what they are." -Guster, "Rocketship" glyph lefkowitz; ninjaneer, freelance demiurge glyph @ [ninjaneering|twistedmatrix].com

3 2

[Twisted-Python] a proposed extension for pb
by Sean Riley Feb. 11, 2002

Feb. 11, 2002

"Publishable" extension to Twisted PB Publishable is a proposed new type of distributed object for twisted.spread. It is similar to the Cacheable class (which caches object state information for the duration of a session), but it adds the capability to cache object state information on remote nodes across multiple sessions. Publishable objects would use the local file system on remote nodes to cache object state information. This "published" state data would include identifying information that allows the cached objects to re-establish their relationships with their server-side counterparts the next time that the object is activated during a session with the same server. The published data for an object would include: - the server that it came from - the service that the object was part of - the perspective/identity that it was accessed through - the identity of the object - the date and time of the state snapshot Some of this data would be shared for multiple objects instances from the same publishing location and could possibly be embedded in the file names or directory structure of the local cache. The timestamp of the snapshot of the object state could be used to allow auto-refreshing of state of published objects. When a published object is re-activated, if it's timestamp is before the timestamp of it's server-side counterpart, the it could be updated with the new state of the server-side object. (this should happen transparently _before_ the object instance is available to client-side user code) Published objects on the client would only be re-activated by the server "sending" a new instance of the same to the client. Of course, it doesnt actually send the entire new state for the object, just the identifying information and timestamp - this initiates a handshake sequence that results in the full updating and re-activation of the object. This functionality was originally designed for dealing with persistent world data for online games - the world state data including houses, terrain, items on the ground, etc. However, it appears to have much broader applicability and could be used for fairly generic replication and clustering of application data. Issues: * "stateless" object references could be a generic solution to the server identification problem. some kind of pb:// URL to identify publishable objects... (and/or all types of Twisted objects) * Re-caching or re-publishing of objects through hierarchies of Twisted servers... * the overhead of the handshaking process that re-activates published objects could introduce significant latency. care should be taken to minize the amount of back-and-forth between client and server ---- "If it's not running programs or fusing atoms, it's just bending space.", Ken Macleod "That's it, I'm outta here.", Homer Simpson's Brain Sean Riley sean(a)ninjaneering.com

2 1

[Twisted-Python] Documentation.. On a wiki!?
by Christopher Armstrong Feb. 11, 2002

Feb. 11, 2002

Yes, that's right. http://twistedmatrix.com/users/carmstro.twistd/static/moin/wiki/cgi-bin/moi… (ok, yeah, it's a long URL. deal.) So, the idea is to use MoinMoin for Twisted's documentation. I have the skeleton ported as well as one or two docs (and I'm working on transcribing the rest of the docs to fit this framework). So, this is my official submission for "what should Twisted use for documentation?". Yes, I do realize that I'll probably need to make lots of customizations for this to work well, and maybe even some tools for dealing with the wiki without using the web. (ie, CLI tools etc). -- Chris Armstrong << radix(a)twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/

4 5

[Twisted-Python] twisted.enterprise / transactions
by Bob Ippolito Feb. 11, 2002

Feb. 11, 2002

I've been looking into twisted.enterprise.. and I have a few questions It seems that enterprise expects that you want to commit data for every successful query? This certainly makes things simpler, as with PostgreSQL a separate backend (connection) is going to be running for every connection to that database, which means the thread pool would require some more complicated management. There ought to be a way to set it up such that your callbacks can do more processing and guarantee that it happens in the same thread, so you get the same connection, and don't have to commit every time. Committing after every query kinda defeats the purpose of having transactions at all, unless you do everything in user defined functions (stored procedures) that use transactions themselves. Similarly, what's the point of rolling back on error if you can't use transactions anyways? If it errored, it didn't do anything anyways. One more thing, do you need to do anything with threadable before using enterprise? -bob

3 2

[Twisted-Python] subclassing twisted.web?
by Kendall Clark Feb. 11, 2002

Feb. 11, 2002

Hi, I'm playing around with some REST ideas[1], and I want to use this approach to build a web-forum-like[2] app for one of my busy content sites. I want to use a standalone, Python-based http server for this app, so I've been looking at the simple http servers in the Python lib, Zope's Z3, Medusa, and twisted.web. For various reasons[3], I'd like to try twisted.web first, but I have a few qestions -- (1) Is there a 'servlet' or other programming model to use with twisted.web? If so, is there any example code? How can I get started? In other words, how are people building Web apps with twisted.web? (2) I'm also playing around with the idea of 'ad hoc http servers', i.e., lightweight servers that do one thing and one thing well, which gets integrated into an existing site using something like Apache's mod_rewrite and mod_proxy. So if I wanted to build a specialized twisted.web that only did one thing, is there a class I can subclass or methods I can override? In other words, I want to specialize the bit(s) of twisted.web which map REQUEST.URI to a local entity; and I want to do so for particular HTTP methods (specifically, GET, POST, DELETE) and return the appropriate non-implemented HTTP response for everything else (i.e., 404 for non-existent URIs and <whatever> for the other HTTP methods). I looked at the twisted.web source briefly, but nothing leapt out at me, alas. Thanks, Kendall Clark Footnotes: [1] http://internet.conveyor.com/RESTwiki/moin.cgi [2] Yes, I looked at twisted.forum long enough to know that I can't use it; this forum app has to be fairly specialized to fit into an existing site. [3] If for no other reason, Z3 doesn't seem to have been busted out of Zope yet (as has ZODB, yay!), and I don't have the time or energy to work on that just to use it cleanly. Plus, I'm looking for reasons to use twisted.

4 5

[Twisted-Python] Words.Participant capabilities
by Kevin Turner Feb. 11, 2002

Feb. 11, 2002

So, I was looking at doing /whois for words.ircservice, and found that lots of accessors weren't available, and there may be a bunch of questions as to whether they should be. One central question is "Do queries about a participant get answered by the server, or by the participant's client?" Having the server answer the questions is faster and cuts down on traffic, particularly if it's a question that everyone is frequently going to be asking about everyone else. But letting the client provide the answers gives the client more freedom to protect their privacy by refusing to answer, or lying, etc. ("No... she's not home. Really. You just missed her. No, that's not her voice in the background, that's just the TV.") More specific points: There's no way for a Words client to determine the online status of another Participant without adding that person to their contact list. Should there be? Almost definately. Unless for some reason you *want* them to have to go through the hurdle of getting you added to their contact list. More user information. Should a Words client be able to look up another Participant and maybe find out what their Identity is, and maybe get a few bits of meta-data out of that? Anything from a single IRCNAME-style string to a contact-manager VCard. Server descriptions. The best I've seen is something like self.service.serviceName, which in practice always yields "twisted.words". How can we get something more descriptive, like "The Official Words Service Of The 2002 Olympics" or "pb://192.168.0.2/twisted.words/"? When we get inter-server connections going, do we want to disclose which server a participant initially signed on to? Do we want to disclose the internet address of the participant's client? Away messages and idle times. Words doesn't have these. Should it? That's all for now, - Kevin, (who is still NOT wasting coding time on IRC servers.) -- The moon is new, 1.9% illuminated, 28.2 days old.

2 3

[Twisted-Python] http://www.cs.wustl.edu/~schmidt/patterns-ace.html
by Moshe Zadka Feb. 11, 2002

Feb. 11, 2002

Do we have this in Python?

2 1

[Twisted-Python] International Python Conspiracy 10
by Glyph Lefkowitz Feb. 10, 2002

Feb. 10, 2002

Some members of the Twisted development team, including myself, attended IPC10 this last week. ( http://www.python10.com/ ) In general, the conference was a huge success. The talk that Moshe Zadka and I gave was heavily attended. Various materials related to the conference, including photos, the paper, and erratta are available at: http://twistedmatrix.com/users/glyph/ipc10 There will probably be a few more additions, since I've been really busy after getting back from the conference. Also, most of the Twisted development team met in meatspace for the first time. If you were there, either at the paper presentation or at the Birds of a Feather session, thanks for dropping by! We got some good feedback from the people who attended both of these, and that was mainly that our key problem is (surprise) documentation. It was hard to decide what features of the conference to describe in detail here, since I had a lot of fun and met a lot of people, so I'll focus on what impact these things will have on the future development of Twisted itself. There was an incredible amount of interest in Twisted; I found that often, rather than trying to generate interest, I was having to keep people's expectations low. The chief reason was that Twisted doesn't have very good documentation, and so it's difficult for end-users to get into it. I had underestimated how useful something like Twisted could be to the average web developer. Currently I'm trying to develop a documentation strategy, and I'm still not sure what form it will take. If you are interested in writing documentation, but don't understand Twisted well enough to do so, please contact me and let me know what information you need to get started. The file doc/index.html in the distribution is an outline of the docs we need -- there is nobody signed up to work on them yet. A few people have mentioned their interest, and if we're lucky, enough time will clear up in all of our schedules to permit working on that. While Developer Day was going on, the Twisted team met outside the conference to talk about the Version 1.0 release strategy. I'd like to get to 1.0 by about april, since I think we've already got a lot of functionality, and one of the things that's making it difficult to document is that it changes all the time. It is easiest to define release criterea when your test suites are written by someone else. We hope to leverage that by using use-cases derived from other sorts of server software for those parts of Twisted which are not really integrated: we can tell when twisted.mail is at the postfix/qmail level of mail application, when twisted.web can compete with apache, and when twisted.names can replace BIND. Those are all going to be release criterea, but we also need some way to decide when our integration between services is good enough. Since including them in this email was making it rediculously long, I've put up a webpage that is a first draft at figuring out what we need for 1.0: http://twistedmatrix.com/users/glyph/twisted/one-point-oh.html Twisted Developers (especially those not at IPC10), your comments are appreciated. Hope to see you all there next year! -- "Cannot stand to be one of many -- I'm not what they are." -Guster, "Rocketship" glyph lefkowitz; ninjaneer, freelance demiurge glyph @ [ninjaneering|twistedmatrix].com

1 0

[Twisted-Python] Documentation
by Shandy Brown Feb. 8, 2002

Feb. 8, 2002

Hi. Glyph invited me to share my thoughts about the state of Twisted Documentation, and why I chose not to use Twisted in my project, Metagame-Sector ( http://sjbrown.geeky.net/metagame-sector/ ). I guess the best way to explain why I didn't choose Twisted is to look at what I did choose, SimpleXMLRPCServer ( http://www.python.org/doc/current/lib/simple-xmlrpc-servers.html ). My project and my attitudes are such that I don't want to spend a lot of time on client-server implementation. I already had a working 'standalone' implementation, and I wanted to add on the client-server "Feature". And for this, XMLRPCServer was great. To make my Game object listen for requests on the internet, all i had to do was call register_instance( myGame ) (ok, it was a little more complicated than that -- i had to resolve threading and pickling issues, but that got me started ) I was able to read this article: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81549 and the SimpleXMLRPCServer docs linked above, and I was good to go. Some say a picture is worth a thousand words; When learning APIs, an example (as above) is worth a thousand help()s. In comparison, Twisted offerred me this as documentation: http://www.twistedmatrix.com/page.epy/docs/writing-servers.html In a *subjective* nutshell, this is hard to read. Also, coming from my background, it doesn't tell me how do do what I want to do, which is: extend my already existing class to make it listen to the internet for requests. An ***example*** would really help out here. Hope this helps let you understand one outsider's view of the documentation. sjbrown

1 0