[TransWarp] is there a chance that SEF class-tree's will be pickle-able??

Phillip J. Eby pje at telecommunity.com
Thu Apr 4 12:49:27 EST 2002

(By the way, I've just checked in pickling support for nested classes; note 
that this does not handle removing Once attributes from the pickled state, 
but should at least get you started.)

At 04:52 PM 4/4/02 +0200, Ulrich Eck wrote:
>Hi phillip,
>>>Is there a chance that we can use Pyro with SEF/Transwarp (Class-Trees)
>>If pickling is the only problem, then yes.  I'm curious, however, why you
>>would need to pickle an entire application for use with Pyro; it seems
>>strange to me to send an entire application over-the-wire!
>the point here is, that i have a setup like this:
>several processes/parts running on different machines e.g.:
>1. DataManager (DM):
>  - uses SEF.Database (here is the first ClassTree i want to use)
>  - everytime an object changes, other services (on other machines)
>    need to know about this change and have the right to veto.
>2. TransactionManager (TM):
>  - controls all transactions
>  - e.g. DataManager registers it's object-changes to TM
>    and only if all other Services (e.g. ImapFolder-Service)
>    succeed with the changes, the data is written by the DM
>3. Controller:
>  - knows, which Service needs to be informed about the current change
>  - keeps track of the status of the modifications
>4. XXX-Service:
>  - e.g. Service for creating HomeDir's, ImapFolders, DNS/DHCP configs ...
>  - runs on all hosts, that need to be changed for a certain mod.
>5. Administrative-Client(AC):
>  - GUI or WebBased Client for Administrative Tasks.
>the best example why i want to access class-trees is the DataManager:
>from my AC i would like to say:
>  <remote-object-reference-to-DM>.User.getItem(<mykey>)
>and get back an MyDatabase.Accounts.PosixAccount Element.
>without using an interface for every single Element-Type (when using
>CORBA for example) it would be necessary to transfer the bytecode
>of the current Element-Definition over the net (most convinient solution).

Pickling won't do that.  It doesn't transfer code, only data.  The class 
has to exist on the other side.

>this is why i tried to transfer the App .. it was just a test if the
>above would be possible ...
>.. any comments ??

If I were creating a distributed GUI like this, I'd put the same domain 
model on both the client and server sides, and use different data/dispatch 
modules.  The client side would implement its data model by retrieving data 
from the server for commonly used batches of attributes, and implement 
other methods by calling remote methods on the server.

If you're looking for a way to do make the existence of the network 
distribution invisible, forget about it.  Such a thing doesn't exist, and 
where it does exist, you don't want it.  You will pay severe penalties in 
both performance and maintenance.  It's much better to have explicit 
interfaces between processes; indeed, entire books have been written about 
why, and what it's better to do instead.  A good one is "Business Objects : 
Delivering Cooperative Objects for Client-Server", by Oliver Sims.

More information about the PEAK mailing list