[Twisted-Python] Unpersistable instead of pb.Avatar
![](https://secure.gravatar.com/avatar/e93e18f71a5821a54c233690506bdbf7.jpg?s=120&d=mm&r=g)
If I try to instance a pb.Avatar subclass and send it to a peer manually, the object that the peer receives is an Unpersistable instead of a real remote reference to the pb.Avatar. How do I fix this and actually send out new perspectives to users? Here's why I want to do this: Suppose I have a network chess program using perspective broker. When a user process logs in it receives a remote reference to a perspective, which is an instance of a pb.Avatar subclass. Suppose that perspective manages the user's ability to interact with a game lobby. For example, the perspective may implement perspective_joinGame allowing the user to partake in a game of chess. This part I know how to do using the cred system. Now suppose the user wants to join multiple games of chess simultaneously. It doesn't make sense to use the same perspective in both games because then every time the user wanted to announce intended action we'd have to constantly pass around extra objects to keep track of which game that perspective is trying to interact with. A similar problem occurs if the same user wants to play as both players in a single game. In other words, it would be nice to separate the responsibilities of the user from those of the "player." If I'm not thinking about this correctly please advise. Thank you for your time, Daniel Sank
![](https://secure.gravatar.com/avatar/b210d1846bf3d93cee9165c1ad9d522d.jpg?s=120&d=mm&r=g)
Hi, How do I fix this and actually send out new perspectives to users?
pb.Avatar is not a Referenceable object, the object which is sent when a client login is a wrapper againt the pb.Avatar object built like this: // pb.py L1327 if not IJellyable.providedBy(avatar): avatar = AsReferenceable(avatar, "perspective") So I suppose you can wrap your avatars object just like this before sending them, "OR" you can make you own implementation of "an avatar" (implementing IPerspective interface) and make it IJellyable at first place. It doesn't make sense to use the same perspective in
both games
I don't see why not personally. Your Avatar is supposed to represente a "user" after that, it is up to you to define what a "User" is for your application. If a "user" is a "physical person", so your avatar could play several games at once, your avatar could then have a list of "played games" (for examples). If your "user" is a couple of ("physical person" + "a game") so each person playing a game will represent a different "user" in the point of view of your application. etc. it would be nice to separate
the responsibilities of the user from those of the "player."
As I said the avatar or the user has the responsabilites that you will give to it. I don't think Twisted makes any asumption about that (IMHO). -- Nacim.
![](https://secure.gravatar.com/avatar/e93e18f71a5821a54c233690506bdbf7.jpg?s=120&d=mm&r=g)
I can think of two reasons. First, suppose that I would like to participate in two different games of chess at the same time. Suppose my Avatar class has a method for moving the chess pieces perspective_movePjece(startSquare, endSquare) If it is possible that this Avatar is playing more than one game then this method doesn't have enough context to get the job done. Either I have to use two method calls perspective_selectGame(nameOfGameICareAboutNow): self.nameOfSelectedGame = nameOfGameICareAboutNow perspective_movePiece(startSquare, endSquare) or I have to require that the client side call pass in the game as an argument perspective.callRemote("movePiece", startSquare, endSquare, whichGame) I find both of these unsatisfying. In the first case I've basically reverted to a remote procedure call style interface with calls that aren't even atomic, and in the second I require the user to explicitly declare the context of the call. This seems to miss the point of remote objects. I'd much rather have the games be instances of Viewable and have different perspectives into each one so that invocations of callRemote on my references to those Viewables automatically come with the proper context. This is why I want multiple Avatars per human user. The second reason is that one human may want to play as two distinct players in the same game. In that case I need to be able to change my client side representation of the published objects as the human switches between the players. Here again we need multiple perspectives to get the job done.
I explain above why I don't like this solution.
This lumps the "user" and the "player", which I would like to avoid.
That's interesting. Thanks.
![](https://secure.gravatar.com/avatar/b210d1846bf3d93cee9165c1ad9d522d.jpg?s=120&d=mm&r=g)
Hi, How do I fix this and actually send out new perspectives to users?
pb.Avatar is not a Referenceable object, the object which is sent when a client login is a wrapper againt the pb.Avatar object built like this: // pb.py L1327 if not IJellyable.providedBy(avatar): avatar = AsReferenceable(avatar, "perspective") So I suppose you can wrap your avatars object just like this before sending them, "OR" you can make you own implementation of "an avatar" (implementing IPerspective interface) and make it IJellyable at first place. It doesn't make sense to use the same perspective in
both games
I don't see why not personally. Your Avatar is supposed to represente a "user" after that, it is up to you to define what a "User" is for your application. If a "user" is a "physical person", so your avatar could play several games at once, your avatar could then have a list of "played games" (for examples). If your "user" is a couple of ("physical person" + "a game") so each person playing a game will represent a different "user" in the point of view of your application. etc. it would be nice to separate
the responsibilities of the user from those of the "player."
As I said the avatar or the user has the responsabilites that you will give to it. I don't think Twisted makes any asumption about that (IMHO). -- Nacim.
![](https://secure.gravatar.com/avatar/e93e18f71a5821a54c233690506bdbf7.jpg?s=120&d=mm&r=g)
I can think of two reasons. First, suppose that I would like to participate in two different games of chess at the same time. Suppose my Avatar class has a method for moving the chess pieces perspective_movePjece(startSquare, endSquare) If it is possible that this Avatar is playing more than one game then this method doesn't have enough context to get the job done. Either I have to use two method calls perspective_selectGame(nameOfGameICareAboutNow): self.nameOfSelectedGame = nameOfGameICareAboutNow perspective_movePiece(startSquare, endSquare) or I have to require that the client side call pass in the game as an argument perspective.callRemote("movePiece", startSquare, endSquare, whichGame) I find both of these unsatisfying. In the first case I've basically reverted to a remote procedure call style interface with calls that aren't even atomic, and in the second I require the user to explicitly declare the context of the call. This seems to miss the point of remote objects. I'd much rather have the games be instances of Viewable and have different perspectives into each one so that invocations of callRemote on my references to those Viewables automatically come with the proper context. This is why I want multiple Avatars per human user. The second reason is that one human may want to play as two distinct players in the same game. In that case I need to be able to change my client side representation of the published objects as the human switches between the players. Here again we need multiple perspectives to get the job done.
I explain above why I don't like this solution.
This lumps the "user" and the "player", which I would like to avoid.
That's interesting. Thanks.
participants (2)
-
Daniel Sank
-
Flint