[Twisted-Python] Is a Viewable Cacheable a good idea?
Suppose I want to make a networked stockroom program with perspective broker. We have a user side client object, class Client(pb.Referenceable): def connect(self): # host, port, factory, and credentials come from elsewhere reactor.connectTCP(host, port, factory) d = self.factory.login(credentials, self) d.addCallback(self.connected) def connected(self, perspective): if perspective: self.perspective = perspective and a "corresponding" server side User, class User(pb.Avatar): def __init__(self, name, server, mind): self.name = name self.server = server self.client = mind #This is a remote reference to a Client def logout(self): ...logic... We have the IRealm implementer, @implementer(portal.IRealm) class Server(object): """I manage games and produce Avatars""" def __init__(self, loggingPath): self.users = {} self.stockrooms = set() def requestAvatar(self, avatarId, mind, *interfaces): assert pb.IPerspective in interfaces user = self.users.setdefault(avatarId, User(avatarId, self, mind)) return pb.IPerspective, user, user.logout and finally we have the Stockroom class Stockroom(object): ...logic... Now I'd like for my Clients to be able to remove/add items to the stockroom. Using only the code above I'd have to add perspective_* methods to the User. These methods would direct the Client's intent to the appropriate Stockroom. Changes made to the Stockroom would then have to be announced to any interested Clients by invoking the appropriate Users' mind property. This seems very awkward. I'd rather just have the Stockrooms be Viewable so that Clients can invoke methods on them directly. If the Stockroom were _also_ Cacheable then changes on a Stockroom would automatically propagate to the client process. Is simultaneously sub-classing Viewable and Cacheable a good idea? Am I thinking about this properly? Regards and thanks in advance, Daniel Sank -- Department of Physics Broida Hall University of California Santa Barbara, CA 93117 (805)893-3899
Hi,
Is simultaneously sub-classing Viewable and Cacheable a good idea? I am not sure it would work, at least not as you expect. Viewable and Cacheable both implement a different version of jellyFor (which will decides how object is seen on the other side of the connection). If you sub-class both of them your resulting class will act either as a cacheable or as a viewable depending on how you sub-class them -- at least for the serialization part.
For your problem, It seems to me that you're trying to do 2 things:
1 - manage a server side object of stockroom(s)
2 - keep a copy of that object(s) synchronized in clients.
So may be (IMHO) you could have one viewable object acting like a
stockroom-manager that clients will (remote)call to make changes on the
server side stockroom-object,
And a cacheable stockroom-object, that you will sync with client.
That said, note that, there is no magic in the sync process when using
cacheable, you will have to propagate the change made to the cacheable
object yourself, by implementing the observe_ methods.
And when you make any changes to the server copy you will have to call
those observe_ methods on all clients, just as you said you would do in
your example.
Another option would be to stockroom object with copyable items and
implement getter method in the stockroom-manager, so clients would be able
to query only data that they need, when they need it, and then do not fire
all the sync stuff each time your stockroom is updates.
Besides cacheable object are said to be used for big object that do not
change frequently, which is not the case of your stockroom I guess.
Hope this help.
--
Nacim.
2013/11/12 Daniel Sank
Suppose I want to make a networked stockroom program with perspective broker. We have a user side client object,
class Client(pb.Referenceable): def connect(self): # host, port, factory, and credentials come from elsewhere reactor.connectTCP(host, port, factory) d = self.factory.login(credentials, self) d.addCallback(self.connected)
def connected(self, perspective): if perspective: self.perspective = perspective
and a "corresponding" server side User,
class User(pb.Avatar): def __init__(self, name, server, mind): self.name = name self.server = server self.client = mind #This is a remote reference to a Client
def logout(self): ...logic...
We have the IRealm implementer,
@implementer(portal.IRealm) class Server(object): """I manage games and produce Avatars""" def __init__(self, loggingPath): self.users = {} self.stockrooms = set()
def requestAvatar(self, avatarId, mind, *interfaces): assert pb.IPerspective in interfaces user = self.users.setdefault(avatarId, User(avatarId, self, mind)) return pb.IPerspective, user, user.logout
and finally we have the Stockroom
class Stockroom(object): ...logic...
Now I'd like for my Clients to be able to remove/add items to the stockroom. Using only the code above I'd have to add perspective_* methods to the User. These methods would direct the Client's intent to the appropriate Stockroom. Changes made to the Stockroom would then have to be announced to any interested Clients by invoking the appropriate Users' mind property.
This seems very awkward. I'd rather just have the Stockrooms be Viewable so that Clients can invoke methods on them directly. If the Stockroom were _also_ Cacheable then changes on a Stockroom would automatically propagate to the client process.
Is simultaneously sub-classing Viewable and Cacheable a good idea?
Am I thinking about this properly?
Regards and thanks in advance, Daniel Sank
-- Department of Physics Broida Hall University of California Santa Barbara, CA 93117 (805)893-3899
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
So may be (IMHO) you could have one viewable object acting like a stockroom-manager that clients will (remote)call to make changes on the server side stockroom-object, and a cacheable stockroom-object, that you will sync with client.
Now that I've been working on this for a while and understand what _doesn't_ work I see why your suggestion here is a very good one. Thank you. The one funny aspect of using a single manager object is that whenever I want to modify an element in the stockroom I have to pass the manager a reference to the object I'm trying to modify: myViewpointToTheManager.callRemote("purchaseItem", myRemoteCacheOfSomeItem) It seems slightly distasteful to have to call a generic purchase method for _any_ object I might want to buy. That said I think I've figured out a good way to handle this whole thing. I attach to this email a file containing some classes that allow interaction both by talking to a Viewable manager or by invoking remote methods on the managed objects themselves. An explanation of intended use is given in the source code. I hope this is helpful to others.
participants (2)
-
Daniel Sank
-
Flint