[Twisted-Python] Re: communication idioms with Perspective Broker

Antony Kummel antonykummel at yahoo.com
Sun Jul 24 12:33:11 EDT 2005


Hi David,

 

Thanks a lot for your response. It seems that your solution fulfills most of what I wanted to achieve, so it was a great help.

 

This is how I understand the registry/manager/wrappers system:

   The meaning of the wrappers is that
      referenceables are transferable to third parties who get their flow pass through the middle process, and 
      that the wrappers get reconnected automatically

   If I understand correctly, the only purpose of the registry is to provide an interface to enable the re-connection of the wrappers.
   The purpose of managers is simply to dispense data and state objects.

 

Questions:

   Do managers only dispense state and data, or do they also provide state control?
   Do cacheables (state objects) re-connect? Is there any reason why they shouldn’t?
   Regarding multi-layer wrapping, how do cacheables go from the original server to the final client without becoming unjellyable in the middle?

 

Thanks,

 

Antony Kummel

 

 

P.S.

 

There are some things I am considering to do differently, and it would be interesting to hear your opinion.

 

The system I had in mind:

   I like and want to adhere to the data/state distinction you made.
   Events will be handled locally by remote caches, based on changes in the cached data (this may be accomplished degenerately, by not exposing anything other than the event).

 

Differences from your system:

   I would like all of my referenceables and cacheables in my system to be re-connecting. This to some extent cancels the need for managers, because any dynamically changing object is re-connecting.
   Instead of (or possibly in addition to) manager objects, I want to have what I call Seed objects, which represent a combination of state, data and referenceables (all optional). These seeds will be copyable, and will include the knowledge required to retrieve their components.
   The seed objects will represent the basic objects of the system (like users), and will provide control and access to their entire data/state.
   The main reasons for seeds are:
      I want state, data and control to be provided by the same object for clarity, and not have each of them require an individual query. For example, a user will have Name, email address, etc. as data, online/offline as state, and a send_message method.
      I want state objects, referenceables, and possibly data associated with a Seed to be retrievable from a Server different from the one who dispensed the Seed (for example, the database may provide a seed and the associated user-changeable data, but the state may be kept by a different server). For example, the user’s data may be stored in a database, his online/offline state retrieved from a presence server, and sending him a message may require connecting to his workstation.


 

		
---------------------------------
 Start your day with Yahoo! - make it your home page 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20050724/fa7fdaad/attachment.htm 


More information about the Twisted-Python mailing list