Interesting solution.

Actually there are two problems here:

1. a specific issue with migration methods - need to provide new addressses. I got round this by simply having the Migrator handler initialized with an array of spare addresses, which are popped off to migrated children. So the handler itself is the naming authority.

2. a general issue with coupling. I came to the conclusion that Handler objects need to be tightly coupled with the Distributed object, which is basically just a facade. Handler objects supply all the functionality for handling messages, so they need to be able to send messages back, etc.

So now I initialize Handlers with the Distributed object which uses them. If an object requires special behaviour to use a handler, you subclass the handler and provide the special behaviour from the Distributed object's public methods.

Example: to serialize using Storable, I need to undef a HTTP::Daemon object in Distributed::Transport, because it has a blessed socket which I can't serialize. Of course, if I am using a different transport, this won't apply. Rather than adding migration specific stuff to Net::Distributed::Transport, I can just subclass the Migrator to be Migrator::HTTP, and to automatically undef the Daemon and bring it back to life after subclassing.

I don't think there is a better solution than this. To provide object-specific behaviour, you either subclass the object, or subclass a related handler. As Distributed is meant to be a facade, subclassing it feels wrong.

Thanks for your comments. Net::Distributed has had some changes which I will upload shortly; Net::Distributed::Space is coming soon... woohoo.

dave hj~