Mailman 3 September 2002 - Twisted

Re: [Twisted-Python] Is X.25 supported?
by Eric C. Newton Sept. 17, 2002

Sept. 17, 2002

Twisted does prevent it, but there is no built-in support. This is not suprising since X.25 APIs are different on nearly every platform. I tried re-patching my changes back in recently and had little success. I may come back to this in a couple of months. -Eric On Tue, Sep 17, 2002 at 06:51:26PM +0200, Sergio Lobo wrote: > Hello, > > I just found the article below on the web. Would anybody please let me know if > Twisted-Python provides any support for the X.25 protocol? > … [View More]

1 0

[Twisted-Python] Is X.25 supported?
by Sergio Lobo Sept. 17, 2002

Sept. 17, 2002

Hello, I just found the article below on the web. Would anybody please let me know if Twisted-Python provides any support for the X.25 protocol? Kind regards Sergio Lobo [Twisted-Python] adding a new connection type Eric C. Newton twisted-python(a)twistedmatrix.com Sun, 26 May 2002 22:30:45 -0400 * Previous message: [Twisted-Python] adding a new connection type * Next message: [Twisted-Python] adding a new connection type * Messages sorted by: [ date ] [ thread ] [ subject ] [ … [View More]

2 1

[Twisted-Python] X.25 for Python
by Sergio Lobo Sept. 17, 2002

Sept. 17, 2002

Hello Eric, I just found the article below on the web. Would you please let me know if Twisted-Python provides support for X.25? Kind regards Sergio Lobo [Twisted-Python] adding a new connection type Eric C. Newton twisted-python(a)twistedmatrix.com Sun, 26 May 2002 22:30:45 -0400 * Previous message: [Twisted-Python] adding a new connection type * Next message: [Twisted-Python] adding a new connection type * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] … [View More]

1 0

[Twisted-Python] serial datatype in t.e.row
by Sean Riley Sept. 16, 2002

Sept. 16, 2002

I have been looking at adding support for "serial" columns into twisted.enterprise.row and it appears to be harder than i originally thought. Serial columns auto-increment when a row is inserted so that the application doesnt have to manage the value of the index manually. So: CREATE TABLE mytable ( column1 serial, column2 int ); INSERT INTO mytable (column2) VALUES (33); will actually auto-increment the sequence for "column1" and use the next value. But.. using twisted … [View More]

4 5

Re: [Twisted-Python] persistence interface
by Laura Creighton Sept. 16, 2002

Sept. 16, 2002

There is a new persistence-SIG mailing list on python.org discussing things like this, er, not right now but last month (things have become fairly quiet). If you've ever thought -- Persistence would be so much easier if only Python had capability XYZ -- now is the time to mention it, when GvR wants to make changes to support persistence. Laura

1 0

[Twisted-Python] persistence interface
by Sean Riley Sept. 15, 2002

Sept. 15, 2002

Glyph and I talked about persistence interface for use in twisted.enterprise initially but with possibly broader implications: class IPersistence(Interface): """I can generate data to persist my current state. The persistent data must be composed of basic types that can be handled by common data storage systems (relational data bases, XML, etc). The data returned shouldn't contain other complex python objects, lists or dictionaries. """ def getStateToPersist(self): """Return a … [View More]

4 3

RE: [Twisted-Python] Perspective vs. Identity question
by Brian Warner Sept. 15, 2002

Sept. 15, 2002

> sounds like you are on the right track. For another example, take a look at > twisted.enterprise.dbcred. It has two authorizers that create perspective > and identities from a relational database and a "reflector" which is another > type of data source. Thanks for the confirmation. This stuff is finally starting to make sense. You're right, dbcred is a good example. SQL is still pretty foreign to me, but somehow seeing the SQL tables and the way dbcred is accessing them helps me … [View More]grok the identity/perspective stuff better. The fact that it's a different style (building Identities on the fly rather than having them pre-built) helps a lot. So.. the Identity doesn't really have to exist before the call to .getIdentityRequest().. it might be pre-made, or pulled out of a database by name (or other persistent structure), or created with data retrieved from a third party, or just faked altogether (like a chat service that lets anybody log in, .getIdentityRequest() could just make a new Identity for every caller, maybe enforcing unique names). And the same is true for the Perspectives? .getPerspectiveRequest() could retrieve an existing Perspective or create a new one on demand? I guess if the perspective is supposed to hang around (like, um, say a chat service that remembers user state between logins) then it shouldn't get deleted from the service when the .detach() method is called. Ah, but it could get saved to disk and then dropped from memory. And then reloaded when they log in again. Hence .cachePerspective() and friend. Enlightenment dawns. I keep coming up with more questions, but the process of phrasing the question in a concrete manner is letting me figure out the answer without asking it. Interesting. I think that means I'm past some inflection point. Last rhetorical question (which I ask so that someone can tell me if I'm wrong). There should be a roughly one-to-one correspondence between perspective subclasses and service subclasses, right? Each service's .getPerspectiveNamed method will create arbitrarily many Perspective objects, with different names, for different Identities, but (generally) always of the same class? MyFooService will have a bunch of instances of MyFooPerspective, etc? The hierarchy looks something like: Application Authorizer Identity[0] username, password servicenameA,perspectivenameA servicenameB,perspectivenameB ... Identity[1]... ServiceA servicename="A" PerspectiveA[0] name otherdata PerspectiveA[1].. ServiceB servicename="B" PerspectiveB[0] PerspectiveB[1].. If that were a graph, there'd also be arrows from Identity[0] to both PerspectiveA[0] and PerspectiveB[0]. Ok, that's as much enlightenment as I can take for one day. Somebody tell me if I got it confused. I'll try to write this up somehow so it might help someone else. thanks, -Brian [View Less]

1 0

[Twisted-Python] More DOMTemplate/WebMVC examples
by Donovan Preston Sept. 14, 2002

Sept. 14, 2002

I recently gave a talk about Twisted, DOMTemplate, and WebMVC at the BayPIGgies Python Interest Group meeting in Palo Alto. For the meeting, I created some simple examples that are hopefully self-explanatory. I thought I would post them for anyone who is interested to look at. I also fixed a few bugs while creating these examples (related to error handling) so they will probably work best with CVS head of Twisted. Donovan

1 0

[Twisted-Python] domtemplate examples
by Bruce Mitchener Sept. 14, 2002

Sept. 14, 2002

Hey all, Does anyone have more involved examples (even ones they can only share privately for now) of using DOMTemplate than the one in doc/howto? Examples of form integration and DB integration like outputting lists of things from a result set of a query would all be welcome. - Bruce

2 2

[Twisted-Python] Perspective vs. Identity question
by Brian Warner Sept. 14, 2002

Sept. 14, 2002

So I'm trying to figure out the whole PB thing; I smell a lot of potential there but haven't figured out enough to actually use it yet. I figured a question here might start to clear up my confusion. I'll start with what I think I know so that if I'm wrong someone can correct my understanding. I intend to turn this into some kind of documentation so that my ignorance can be used towards some greater good :). I think I get the PB remote-method scheme up to the level demonstrated in docs/… [View More]examples/pbsimple.py (using pb.connect and remote_* methods). In trying to figure out the Perspective/Identity layer (as in pbecho.py), what I've figured out so far is: Application instances hold an Authorizer, usually a DefaultAuthorizer. A DefaultAuthorizer has a collection of Identity objects, each with a unique identityName. That collection doesn't have to be a static list: .getIdentityRequest() could be overridden to do some kind of asynchronous lookup (LDAP comes to mind). Each Identity has a username and a password. It also has a list of "keys" (.keyring), each of which is a (perspectivename, servicename) tuple. If the remote client knows both username and password for a given Identity, then they are allowed to ask that Identity for any perspective on its keyring by supplying a (servicename/perspectivename) pair. The identity.requestPerspectiveForKey() method is supposed to find the named Perspective (asynchronously), run .attach() on it, then give a reference to the client. Once the client has that remote reference, they can do any perspective_* method they like. So my understanding breaks down in how this is all supposed to work in practice. I keep thinking of it in terms of a login shell or game, where you have a bunch of user accounts, and a user is using their client program to connect in. Let's say there are two Services: Shell and Game, and that the same users are allowed to connect to both. Then: Each user has one Identity object, with a username and password. These Identities could be created ahead of time (say, from /etc/passwd) and stored in the DefaultAuthorizer's list. Or, they might be created on the fly by a custom Authorizer class. The important thing is that .getIdentityRequest returns a valid Identity object when asked. Each user might talk to two potential Perpective objects. When user 'bob' is attached in to do shell stuff, he could use a Perspective called 'bob_shell', which is part of the Shell service. (I think the perspectivename is scoped to the Service, so this could just be named 'bob', but that would make this description confusing). When he is doing game stuff, he could use a Perspective called 'bob_game', part of the Game service. Presumably bob_shell and bob_game are instances of different subclasses of pb.Perspective, one which offers shell-like remote methods and the other offering game-like methods. The cross-user shared state that represents the communal game world could be stored up in the Game Service object, anything that needs to be shared between both the game and the shell could go in the overall Application object. Now, how are those Perspectives supposed to be created? Do they get built ahead of time (at the same time the Identities are made)? Are they supposed to outlast the client connection? In all the doc/example/ programs, a single Perspective is created ahead of time, and then a single Identity is created from that Perspective, using the .makeIdentity() utility method. The largest example I've been able to find is twisted.words, but as far as I can tell it does the same thing.. I think the words.Participant (subclassed from pb.Perspective) hangs around all the time whether or not the client is attached (it has a .status flag that starts as OFFLINE), and the perspectives are always created ahead of time (tap/words.py does svc.createPerspective(n).makeIdentity(pw)) based upon who is allowed to connect. I can see that the Perspective is kind of an in-server proxy for the remote user: the client can make it do anything they want (well, any perspective_* methods at least), and the perspective can outlast the client's connection (its .attached/.detached are called to let it know when the client comes and goes). But if it isn't supposed to (or doesn't need to) outlive the connection, then must it still be created ahead of time? Is identity.requestPerspectiveForKey() allowed to create new perspective objects on the fly? Sorry for the length. Tell me if I'm on the right track here.. if so, I'll try to put together some kind of multi-Perspective example program (maybe the telnet/game thing I just described) with a big how-it-works writeup, something that explains the concepts I just went over. An example+writeup like that would have helped / will help me figure out this part of Twisted.. maybe it could help others too. thanks much, -Brian, twisting a little bit more each day [View Less]

2 1