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
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
