What if both the Color and the Area base class defined the same method,
-perhaps calculate? Where would the implementation come from? The
-implementation that is located for Square().calculate() depends on
-the method resolution order, or MRO, and can change when programmers change
-seemingly unrelated things by refactoring classes in other parts of the system,
-causing obscure bugs. Our first thought might be to change the calculate method
-name to avoid name clashes, to perhaps calculateArea and
-calculateColor. While explicit, this change could potentially
-require a large number of changes throughout a system, and is error-prone,
-especially when attempting to integrate two systems which you didn't write.
What if both the Color and the Area base class defined the same
+method, perhaps calculate? Where would the implementation
+come from? The implementation that is located
+for Square().calculate() depends on the method resolution
+order, or MRO, and can change when programmers change seemingly
+unrelated things by refactoring classes in other parts of the system,
+causing obscure bugs. Our first thought might be to change the
+calculate method name to avoid name clashes, to
+perhaps calculateArea and calculateColor.
+While explicit, this change could potentially require a large number
+of changes throughout a system, and is error-prone, especially when
+attempting to integrate two systems which you didn't write.
Let's imagine another example. We have an electric appliance, say a hair dryer. The hair dryer is American voltage. We have two electric sockets, one of @@ -152,8 +154,8 @@ now you have no hair dryer any more. -
We are going to attempt to solve this problem by writing an Adapter for the
-UKSocket which converts the voltage for use with an American
+
We are going to attempt to solve this problem by writing an Adapter for
+the UKSocket which converts the voltage for use with an American
hair dryer. An Adapter is a class which is constructed with one and only one
argument, the adaptee
or original
object. In this example, we
will show all code involved for clarity:
Now that we have a defined Interface, we can talk about objects using terms
-like this: So, to declare that a class implements an interface, we simply call
- So, to declare that a class implements an interface, we simply
+call Now, let's say we want to rewrite the Now, let's say we want to rewrite
+the As you can see, the If you want If you want The
and AmericanSocket class implements the
-IAmericanSocket interfacePlease give me an object which
+like this:
The
and AmericanSocket class implements the IAmericanSocket interfacePlease give me an object which
adapts
. We can make declarations about what interfaces a certain
class implements, and we can request adapters which implement a certain
@@ -236,12 +237,13 @@
return 120
-UKSocket to the IAmericanSocket
interfacezope.interface.implements at the class level.zope.interface.implements at the class level.AdaptToAmericanSocket
-class as a real adapter. In this case we also specify it as implementing
-IAmericanSocket:AdaptToAmericanSocket class as a real adapter. In
+this case we also specify it as
+implementing IAmericanSocket:
from zope.interface import implements
@@ -325,8 +327,7 @@
-AmericanSocket instance claims to
implement IAmericanSocket, but the UKSocket
-does not. If we wanted to use the HairDryer with the
-AmericanSocket, we could know that it would be safe to do so by
+does not. If we wanted to use the HairDryer with the AmericanSocket, we could know that it would be safe to do so by
checking whether it implements IAmericanSocket. However, if we
decide we want to use HairDryer with a UKSocket
instance, we must adapt it to IAmericanSocket before
@@ -341,8 +342,7 @@
looks in the adapter registry for an adapter which implements the interface for
the given instance's class. If it finds one, it constructs an instance of the
Adapter class, passing the constructor the original instance, and returns it.
-Now the HairDryer can safely be used with the adapted
-UKSocket. But what happens if we attempt to adapt an object
+Now the HairDryer can safely be used with the adapted UKSocket. But what happens if we attempt to adapt an object
which already implements IAmericanSocket? We simply get back the
original instance:MyThing to inherit from pb.Root but
-not implement IPBRoot like pb.Root does,
+MyThing to inherit from pb.Root but not implement IPBRoot like pb.Root does,
use implementOnly:
Index: doc/core/howto/defer.xhtml
===================================================================
--- doc/core/howto/defer.xhtml (revision 30075)
+++ doc/core/howto/defer.xhtml (working copy)
@@ -44,8 +44,7 @@
available (this series of functions is known as a series of
callbacks, or a callback chain), together
with a series of functions to be called if there is an error in the
-asychronous request (known as a series of errbacks or an
-errback chain). The asychronous library code calls the first
+asychronous request (known as a series of errbacks or an errback chain). The asychronous library code calls the first
callback when the result is available, or the first errback when an error
occurs, and the
Deferred object then hands the results of each
callback or errback function to the next function in the chain.
What this means in a practical sense is in Case 1, the callback in line
A will handle a success condition from getDeferredFromSomewhere,
and the errback in line B will handle any errors that occur from either the
-upstream source, or that occur in A. In Case 2, the errback in line C
-will only handle an error condition raised by
-getDeferredFromSomewhere, it will not do any handling of errors
+upstream source, or that occur in A. In Case 2, the errback in line C will
+only handle an error condition raised by getDeferredFromSomewhere,
+it will not do any handling of errors
raised in callback1.
Our original implementation of authenticateUser expected
-isValidUser to be synchronous, but now we need to change it to handle both
+
Our original implementation of authenticateUser expected isValidUser to be synchronous, but now we need to change it to handle both
synchronous and asynchronous implementations of isValidUser. For this, we
use maybeDeferred to
call isValidUser, ensuring that the result of isValidUser is a Deferred,
@@ -414,8 +412,7 @@
-Now isValidUser could be either synchronousIsValidUser or
-asynchronousIsValidUser.
+Now isValidUser could be either synchronousIsValidUser or asynchronousIsValidUser.
It is also possible to modify synchronousIsValidUser to return
@@ -437,8 +434,7 @@
dl = defer.DeferredList([deferred1, deferred2, deferred3])
-
You can now treat the DeferredList like an ordinary Deferred; you can call
-addCallbacks and so on. The DeferredList will call its callback
+
You can now treat the DeferredList like an ordinary Deferred; you can call addCallbacks and so on. The DeferredList will call its callback
when all the deferreds have completed. The callback will be called with a list
of the results of the Deferreds it contains, like so:
consumeErrors parameter will not change the behavior of
-fireOnOneCallback or fireOnOneErrback.
+for the consumeErrors parameter will not change the behavior of fireOnOneCallback or fireOnOneErrback.
@@ -564,8 +559,7 @@
substitute for the docstrings in the Deferred class, but can provide guidelines
for its use.
-There is a parallel overview of functions used by the Deferred's -creator in Generating Deferreds.
+There is a parallel overview of functions used by the Deferred's creator in Generating Deferreds.
There are 2 basic flavors that allow for copying objects remotely. Again,
you can use these by subclassing them. In order to specify what state you want
to have copied when these are serialized, you can either use the Python default
-__getstate__ or specialized method calls for that
+ __getstate__ or specialized method calls for that
flavor.
Index: doc/core/howto/internet-overview.xhtml =================================================================== --- doc/core/howto/internet-overview.xhtml (revision 30075) +++ doc/core/howto/internet-overview.xhtml (working copy) @@ -19,13 +19,13 @@
Twisted Internet contains the various interfaces to the reactor
API, whose usage is documented in the low-level chapter. Those APIs
are IReactorCore,
-IReactorTCP,
-IReactorSSL,
-IReactorUNIX,
-IReactorUDP,
-IReactorTime,
-IReactorProcess,
-IReactorMulticast
+ IReactorTCP,
+ IReactorSSL,
+ IReactorUNIX,
+ IReactorUDP,
+ IReactorTime,
+ IReactorProcess,
+ IReactorMulticast
and IReactorThreads.
The reactor APIs allow non-persistent calls to be made.
Deferreds are quite possibly the single most confusing topic that a newcomer to Twisted has to deal with. I am going to forgo the normal talk about what deferreds are, what they aren't, and why they're used in Twisted. -Instead, I'm going show you the logic behind what they -do.
+Instead, I'm going show you the logic behind what they do.A deferred allows you to encapsulate the logic that you'd normally use to @@ -255,8 +254,7 @@
Two things to note here. First, "- A -" was skipped, like we wanted it to, -and the second thing is that after "- A -", noDecision is called, because -it is the next errback that exists in the chain. It returns a +and the second thing is that after "- A -", noDecision is called, because it is the next errback that exists in the chain. It returns a non-failure, so processing continues with the next callback at "- B -", and the errback at the end of the chain is never called
Index: doc/core/howto/pb-copyable.xhtml =================================================================== --- doc/core/howto/pb-copyable.xhtml (revision 30075) +++ doc/core/howto/pb-copyable.xhtml (working copy) @@ -75,13 +75,13 @@ protocol that involved sending a file-like object with aread()
method that was supposed to used later to retrieve a document. Then imagine
what if that object were created with
-os.fdopen("~/.gnupg/secring.gpg"). Or an instance of
-telnetlib.Telnet("localhost", "chargen").
+ os.fdopen("~/.gnupg/secring.gpg"). Or an instance of
+ telnetlib.Telnet("localhost", "chargen").
Classes you've written for your own program are likely to have far more
power. They may run code during __init__, or even have special
meaning simply because of their existence. A program might have
-User objects to represent user accounts, and have a rule that
+ User objects to represent user accounts, and have a rule that
says all User objects in the system are referenced when
authorizing a login session. (In this system, User.__init__
would probably add the object to a global list of known users). The simple
@@ -127,7 +127,7 @@
that a serialized representation A (of some remote object) can be
unserialized into a local object of type B. It is these objects B
that are the Unjellyable
second argument of the
-setUnjellyableForClass function.
+ setUnjellyableForClass function.
In particular, unjellyable
does not mean cannot be
jellied
. Unpersistable means not
@@ -143,7 +143,7 @@
the remote end sends an object, the class name that they transmit is looked
up in the table controlled by this function. If a matching class is found,
it is used to create the local object. If not, you get the
-
InsecureJelly exception.
InsecureJelly exception.
In general you expect both ends to share the same codebase: either you
control the program that is running on both ends of the wire, or both
@@ -152,7 +152,7 @@
the MyFooziWhatZit class unless you also had a definition for that class. So
it is reasonable for the Jelly layer to reject all incoming classes except
the ones that you have explicitly marked with
-setUnjellyableForClass. But keep in mind that the sender's idea
+ setUnjellyableForClass. But keep in mind that the sender's idea
of a User object might differ from the recipient's, either
through namespace collisions between unrelated packages, version skew
between nodes that haven't been updated at the same rate, or a malicious
@@ -175,19 +175,19 @@
base="twisted.spread.pb">Serializable classes. In this section,
we focus on Copyable.
The copyable subclass of LilyPond is called
-CopyPond. We create an instance of it and send it through
-callRemote as an argument to the receiver's
-remote_takePond method. The Jelly layer will serialize
+ CopyPond. We create an instance of it and send it through
+ callRemote as an argument to the receiver's
+ remote_takePond method. The Jelly layer will serialize
(jelly
) that object as an instance with a class name of
copy_sender.CopyPond
and some chunk of data that represents the
object's state. pond.__class__.__module__ and
-pond.__class__.__name__ are used to derive the class name
+ pond.__class__.__name__ are used to derive the class name
string. The object's getStateToCopy method is
used to get the state: this is provided by pb.Copyable, and the default just retrieves
-self.__dict__. This works just like the optional
-__getstate__ method used by pickle. The pair of
+ self.__dict__. This works just like the optional
+ __getstate__ method used by pickle. The pair of
name and state are sent over the wire to the receiver.
The receiving end defines a local class named ReceiverPond
@@ -200,7 +200,7 @@
base="twisted.spread">pb.RemoteCopy, which is a requirement for all
classes that act in this local-representative role (those which are given to
the second argument of setUnjellyableForClass).
-RemoteCopy provides the methods that tell the Jelly layer how
+ RemoteCopy provides the methods that tell the Jelly layer how
to create the local object from the incoming serialized state.
Then setUnjellyableForClass is used to register the two
@@ -212,12 +212,12 @@
When the receiver unserializes (unjellies
) the object, it will
create an instance of the local ReceiverPond class, and hand
the transmitted state (usually in the form of a dictionary) to that object's
-setCopyableState method.
This acts just like the __setstate__ method that
-pickle uses when unserializing an object.
-getStateToCopy/setCopyableState are distinct from
-__getstate__/__setstate__ to allow objects to be
+ pickle uses when unserializing an object.
+ getStateToCopy/setCopyableState are distinct from
+ __getstate__/__setstate__ to allow objects to be
persisted (across time) differently than they are transmitted (across
[memory]space).
By overriding getStateToCopy and
-setCopyableState, you can control how the object is transmitted
+ setCopyableState, you can control how the object is transmitted
over the wire. For example, you might want perform some data-reduction:
pre-compute some results instead of sending all the raw data over the wire.
Or you could replace references to a local object on the sender's side with
@@ -261,7 +261,7 @@
system. Combined with the fact that Copyable objects return
unchanged from a round trip, this could be used to build a
challenge-response system (in fact PB does this with
-pb.Referenceable objects to implement authorization as
+ pb.Referenceable objects to implement authorization as
described here).
Whatever getStateToCopy returns from the sending object will
@@ -422,21 +422,21 @@
useful to subclass or modify, so simply treat it as a little demon that sits
in your pb.Cacheable class and helps you distribute change
notifications. The only useful thing to do with it is to run its
-callRemote method, which acts just like a normal
-pb.Referenceable's method of the same name. that points at that receiver-side cache. Every time the state of the object
+ callRemote method, which acts just like a normal
+ pb.Referenceable's method of the same name. that points at that receiver-side cache. Every time the state of the object
is changed, you give a message to the observer, informing them of the
change. The other method, stoppedObserving, is called when the
remote cache goes away, so that you can stop sending updates.
On the receiver end, you make your cache class inherit from pb.RemoteCache, and implement the
-setCopyableState as you would for a pb.RemoteCopy
+ setCopyableState as you would for a pb.RemoteCopy
object. In addition, you must implement methods to receive the updates sent
to the observer by the pb.Cacheable: these methods should have
names that start with observe_, and match the
-callRemote invocations from the sender side just as the usual
-remote_* and perspective_* methods match normal
-callRemote calls.
callRemote invocations from the sender side just as the usual
+ remote_* and perspective_* methods match normal
+ callRemote calls.
The first time a reference to the pb.Cacheable object is
sent to any particular recipient, a sender-side Observer will be created for
@@ -447,7 +447,7 @@
described above (in fact it inherits from that class).
After that, your setter
functions on the sender side should call
-callRemote on the Observer, which causes observe_*
+ callRemote on the Observer, which causes observe_*
methods to run on the receiver, which are then supposed to update the
receiver-local (cached) state.
With the pb.Cacheable and pb.RemoteCache
classes in place, bound together by a call to
-pb.setUnjellyableForClass, all that remains is to pass a
+ pb.setUnjellyableForClass, all that remains is to pass a
reference to your pb.Cacheable over the wire to the remote end.
The corresponding pb.RemoteCache object will automatically be
created, and the matching methods will be used to keep the receiver-side
Index: doc/core/howto/glossary.xhtml
===================================================================
--- doc/core/howto/glossary.xhtml (revision 30075)
+++ doc/core/howto/glossary.xhtml (working copy)
@@ -307,8 +307,7 @@
twisted.web.sux.twisted.web.sux.
Imagine how you would write a chat server using PB. The first step might
be a ChatServer object which had a bunch of
-pb.RemoteReferences that point at user clients. Pretend that
+ pb.RemoteReferences that point at user clients. Pretend that
those clients offered a remote_print method which lets the
server print a message on the user's console. In that case, the server might
look something like this:
For now, assume that all clients have somehow acquired a
-pb.RemoteReference to this ChatServer object,
+ pb.RemoteReference to this ChatServer object,
perhaps using pb.Root and getRootObject as
described in the previous chapter. In this
scheme, when a user sends a message to the group, their client runs
@@ -99,10 +99,10 @@
place to keep state is in an object, so this suggests we need a per-user
object. Rather than choosing an obvious nameThe
obvious name is clearly
-ServerSidePerUserObjectWhichNobodyElseHasAccessTo, but because
+ ServerSidePerUserObjectWhichNobodyElseHasAccessTo, but because
Python makes everything else so easy to read, it only seems fair to make
your audience work for something., let's call this the
-User class.
+ User class.
@@ -134,7 +134,7 @@
Again, assume that each remote client gets access to a single
-User object, which is created with the proper username.
User object, which is created with the proper username.
Note how the ChatServer object has no remote access: it
isn't even pb.Referenceable anymore. This means that all access
@@ -143,7 +143,7 @@
As long as Alice only has access to her own User object, she
can no longer spoof Bob. The only way for her to invoke
-ChatServer.sendMessage is to call her User
+ ChatServer.sendMessage is to call her User
object's remote_sendMessage method, and that method uses its
own state to provide the from_username argument. It doesn't
give her any way to change that state.
This restriction is important. The User object is able to
maintain its own integrity because there is a wall between the object and
the client: the client cannot inspect or modify internal state, like the
-.name attribute. The only way through this wall is via remote
+ .name attribute. The only way through this wall is via remote
method invocations, and the only control Alice has over those invocations is
when they get invoked and what arguments they are given.
mattressis a hassle that's best avoided altogether. Again, per-group state implies a per-group object. We'll go out on a limb and call this the -
Group object:
+ Group object:
class User(pb.Referenceable): @@ -208,7 +208,7 @@This example takes advantage of the fact that -
pb.Referenceableobjects sent over a wire can be returned to +pb.Referenceableobjects sent over a wire can be returned to you, and they will be turned into references to the same object that you originally sent. The client cannot modify the object in any way: all they can do is point at it and invoke itsremote_*methods. Thus, @@ -232,7 +232,7 @@ into apb.RemoteReferencewhen it arrives at the client. The client sends it back toGroup.remote_send, and PB turns it back into a reference to the originalUserwhen it gets there. -Group.remote_sendcan then use its.nameattribute +Group.remote_sendcan then use its.nameattribute as the sender of the message.@@ -240,7 +240,7 @@Third party references (there aren't any)
This technique also relies upon the fact that the -
pb.Referenceablereference can only come from someone +pb.Referenceablereference can only come from someone who holds a correspondingpb.RemoteReference. The design of the serialization mechanism (implemented intwisted.spread.jelly: pb, jelly, spread.. get it? Look for @@ -254,7 +254,7 @@ dropped, further limiting the scope of those references.Futhermore, it is not possible for Bob to send his -
Userreference to Alice (perhaps over some other PB channel +Userreference to Alice (perhaps over some other PB channel just between the two of them). Outside the context of Bob's connection to the server, that reference is just a meaningless number. To prevent confusion, PB will tell you if you try to give it away: when you try to hand @@ -287,7 +287,7 @@But again, note the vulnerability. If Alice holds a -
@@ -314,7 +314,7 @@RemoteReferenceto any object on the server side that +RemoteReferenceto any object on the server side that has a.nameattribute, she can use that name as a spoofedfromparameter. As a simple example, what if her client code looked like:There are two techniques to close this hole. The first is to have your remotely-invokable methods do type-checking on their arguments: if -
@@ -325,8 +325,8 @@Group.remote_sendassertedisinstance(from_user, +Group.remote_sendassertedisinstance(from_user, User)then Alice couldn't use non-User objects to do her spoofing, and hopefully the rest of the system is designed well enough to prevent her from obtaining access to somebody else's User object.The second technique is to avoid having the client send you the objects altogether. If they don't send you anything, there is nothing to verify. In this case, you would have to have a per-user-per-group object, in which the -
@@ -353,7 +353,7 @@remote_sendmethod would only take a single -messageargument. TheUserGroupobject is created +remote_sendmethod would only take a single +messageargument. TheUserGroupobject is created with references to the onlyUserandGroupobjects that it will ever use, so no lookups are needed:The only message-sending method Alice has left is -
UserGroup.remote_send, and it only accepts a message: there are +UserGroup.remote_send, and it only accepts a message: there are no remaining ways to influence thefromname.In this model, each remotely-accessible object represents a very small @@ -361,7 +361,7 @@ abilities to each remote user.
PB provides a shortcut which makes this technique easier to use. The -
Viewableclass will be discussed Viewable class will be discussed below.Avatars and Perspectives
@@ -382,11 +382,11 @@For PB, the first question is easy. The Avatar is a remotely-accessible object which can run code: this is a perfect description of -
pb.Referenceableand its subclasses. We shall defer the second +pb.Referenceableand its subclasses. We shall defer the second question until the next section.In the example above, you can think of the
ChatServerand -Groupobjects as a service. TheUserobject is the +Groupobjects as a service. TheUserobject is the user's server-side representative: everything the user is capable of doing is done by running one of its methods. Anything that the server wants to do to the user (change their group membership, change their name, delete their @@ -401,13 +401,13 @@ provides and controls (i.e.brokers) access to Perspectives.Once upon a time, these local-representative objects were actually called -
pb.Perspective. But this has changed with the advent of the +pb.Perspective. But this has changed with the advent of the rewritten cred system, and now the more generic term for a local representative object is an Avatar. But you will still see reference toPerspectivein the code, the docs, and the module namesWe could just go ahead and rename Perspective Broker to be Avatar Broker, but 1) that would cause massive compatibility problems, and 2) -ABdoesn't fit into the whole sandwich-themed naming scheme nearly as +ABdoesn't fit into the whole sandwich-themed naming scheme nearly as well asPBdoes. If we changed it to AB, we'd probably have to change Banana to be CD (CoderDecoder), and Jelly to be EF (EncapsulatorFragmentor). twisted.spread would then have to be renamed twisted.alphabetsoup, and then @@ -417,23 +417,23 @@Despite all we've been telling you about how Avatars are more of a concept than an actual class, the base class from which you can create your server-side avatar-ish objects is, in fact, named -
pb.AvatarThe avatar-ish class is named -pb.Avatarbecausepb.Perspectivewas already +pb.AvatarThe avatar-ish class is named +pb.Avatarbecausepb.Perspectivewas already taken, by the (now obsolete) oldcred perspective-ish class. It is a pity, but it simply wasn't possible both replacepb.Perspectivein-place and maintain a reasonable level of backwards-compatibility.. These objects behave very much like -pb.Referenceable. The only difference is that instead of +pb.Referenceable. The only difference is that instead of offeringremote_FOOmethods, they offerperspective_FOOmethods.The other way in which
+pb.Avatardiffers from -pb.Referenceableis that the avatar objects are designed to be +pb.Referenceableis that the avatar objects are designed to be the first thing retrieved by a cred-using remote client. Just as -PBClientFactory.getRootObjectgives the client access to a -pb.Rootobject (which can then provide access to all kinds of +PBClientFactory.getRootObjectgives the client access to a +pb.Rootobject (which can then provide access to all kinds of other objects),PBClientFactory.logingives client access to a -pb.Avatarobject (which can return other references).pb.Avatarobject (which can return other references).So, the first half of using cred in your PB application is to create an Avatar object which implements
+perspective_methods and is @@ -491,7 +491,7 @@ they can provide it with an optionalclientargument (which must be apb.Referenceableobject). If they do, then a reference to that object will be handed to the realm's -requestAvatarin themindargument.requestAvatarin themindargument.The server-side Perspective can use it to invoke remote methods on something in the client, so that the client doesn't always have to drive the @@ -523,7 +523,7 @@ that is exposed to the remote client.
Second, we created a realm (an object which implements -
IRealm, and therefore implementsrequestAvatar). +IRealm, and therefore implementsrequestAvatar). This realm manufacturesMyPerspectiveobjects. It makes as many as we want, and names each one with the avatarID (a username) that comes out of the checkers. This MyRealm object returns two other objects as well, @@ -534,10 +534,10 @@ Avatars for any which survive the authentication process.Fourth, we made a simple checker (an object which implements -
IChecker) to hold valid user/password pairs. The checker +IChecker) to hold valid user/password pairs. The checker gets registered with the portal, so it knows who to ask when new clients connect. We use a checker named -InMemoryUsernamePasswordDatabaseDontUse, which suggests +InMemoryUsernamePasswordDatabaseDontUse, which suggests that 1: all the username/password pairs are kept in memory instead of being saved to a database or something, and 2: you shouldn't use it. The admonition against using it is because there are better @@ -558,9 +558,9 @@ href="pb-usage.xhtml">before) and attached to a TCP connection. When the connection completes, the factory will be asked to produce a Protocol, and it will create a PB object. Unlike the previous chapter, where we used -.getRootObject, here we usefactory.loginto -initiate the cred authentication process. We provide a -credentialsobject, which is the client-side agent for doing +.getRootObject, here we usefactory.loginto + initiate the cred authentication process. We provide a +credentialsobject, which is the client-side agent for doing our half of the authentication process. This process may involve several messages: challenges, responses, encrypted passwords, secure hashes, etc. We give our credentials object everything it will need to respond correctly (in @@ -568,8 +568,8 @@ used public-key encryption or even fancier techniques).@@ -580,18 +580,18 @@
loginreturns a Deferred which, when it fires, will return a -pb.RemoteReferenceto the remote avatar. We can then do -callRemoteto invoke aperspective_foomethod on +pb.RemoteReferenceto the remote avatar. We can then do +callRemoteto invoke aperspective_foomethod on that Avatar.pbAnonServer.py implements a server based on pb6server.py, extending it to permit anonymous logins in addition to authenticated logins. An -
+ ofAllowAnonymousAccess+AllowAnonymousAccesschecker and anInMemoryUsernamePasswordDatabaseDontUsechecker are registered and the client's choice of credentials object determines which is used to authenticate the login. In either case, the realm will be called on to create an avatar for the login.AllowAnonymousAccessalways produces anavatarId -oftwisted.cred.checkers.ANONYMOUS.twisted.cred.checkers.ANONYMOUS.On the client side, the only change is the use of an instance of -
+Anonymouswhen calling -PBClientFactory.login.Anonymouswhen calling +PBClientFactory.login.Using Avatars
@@ -621,7 +621,7 @@Making Avatars
In the example above, we create Avatars upon request, during -
@@ -633,7 +633,7 @@ Avatar later, once the lookup had completed.requestAvatar. Depending upon the service, these Avatars might +requestAvatar. Depending upon the service, these Avatars might already exist before the connection is received, and might outlive the connection. The Avatars might also accept multiple connections.Here are some possible implementations of -
+MyRealm.requestAvatar:MyRealm.requestAvatar:# pre-existing, static avatars @@ -695,7 +695,7 @@ avatar that a remote client has just attached. The Realm can also ask the protocol to let it know when the connection goes away, so it can then inform the Avatar that the client has detached. The third member of the -requestAvatarreturn tuple is a callable which will be invoked +requestAvatarreturn tuple is a callable which will be invoked when the connection is lost.@@ -727,10 +727,9 @@ represent users, theViewableclass can come into play. This class behaves a lot likeReferenceable: it turns into a -RemoteReferencewhen sent over the wire, and certain methods +RemoteReferencewhen sent over the wire, and certain methods can be invoked by the holder of that reference. However, the methods that -can be called have names that start withview_instead of -remote_, and those methods are always called with an extra +can be called have names that start withview_instead ofremote_, and those methods are always called with an extraperspectiveargument that points to the Avatar through which the reference was sent: @@ -751,7 +750,7 @@ just have per-group objects which inherit frompb.Viewable, and give the user references to them. The localpb.Avatarobject will automatically show up as theperspectiveargument in the -view_*method calls, give you a chance to involve the Avatar in +view_*method calls, give you a chance to involve the Avatar in the process. @@ -767,9 +766,9 @@Notice that the client uses
Index: doc/core/howto/testing.xhtml =================================================================== --- doc/core/howto/testing.xhtml (revision 30075) +++ doc/core/howto/testing.xhtml (working copy) @@ -72,8 +72,8 @@ Theperspective_joinGroupto both join a group and retrieve aRemoteReferenceto the -Groupobject. However, the reference they get is actually to a +Groupobject. However, the reference they get is actually to a special intermediate object called apb.ViewPoint. When they do -group.callRemote("send", "message"), their avatar is inserted +group.callRemote("send", "message"), their avatar is inserted into the argument list thatGroup.view_sendactually sees. This lets the group get their username out of the Avatar without giving the client an opportunity to spoof someone else.tearDownmethod is a good place to put cleanup code: it is always run regardless of whether your test passes or fails (like a bareexceptclause in a try-except construct). Exceptions intearDown -are flagged as errors and flunk the test. -TestCase.addCleanupis + are flagged as errors and flunk the test. +TestCase.addCleanupis another useful tool for cleaning up. With it, you can register callables to clean up resources as the test allocates them. Generally, code should be written so that only resources allocated in the tests need to be cleaned up in @@ -84,7 +84,7 @@ return a Deferred from your test method, setUp, or tearDown and Trial will do the right thing. That is, it will run the reactor for you until the Deferred has triggered and its callbacks have been run. Don't use -reactor.run(),reactor.stop(),reactor.crash()orreactor.iterate()in your tests. +reactor.run(),reactor.stop(),reactor.crash()orreactor.iterate()in your tests.Calls to
reactor.callLatercreateIDelayedCalls. These need to be run @@ -132,7 +132,7 @@Interacting with warnings in tests
Trial includes specific support for interacting with Python's -
@@ -140,7 +140,7 @@ class="API" base="twisted.trial.unittest">TestCase.flushWarnings allows tests to be written which make assertions about what warnings have been emitted during a particular test method. In order to test a warning with -warningsmodule. This support allows warning-emitting code to +warningsmodule. This support allows warning-emitting code to be written test-driven, just as any other code would be. It also improves the way in which warnings reporting when a test suite is running.flushWarnings, write a test which first invokes the code which +flushWarnings, write a test which first invokes the code which will emit a warning and then callsflushWarningsand makes assertions about the result. For example: @@ -161,7 +161,7 @@ method, it will not raise an exception when warnings have been configured as errors. However, if called outside of a test method (for example, at module scope in a test module or a module imported by a test module) then it -will raise an exception. + will raise an exception.