Great!
I had a good talk with a CTO of a company here in New Zealand who is using Scala/Akka full-time.
I was able to clarify quite a few concerns and questions I had.
These were relating to routers, restarting, supervisors, actor references and just about everything TBH.
There was a good solution to the worker problem.
And it became obvious that a Router in Akka parlance is simply a load-balancer and so does not do any management of work distribution.
It being a way to hide many actors was a simple enough concept to have large benefits.
With regard to restarting, an ActorRef (what we call a proxy right now) does not become terminated/dead upon restart.
But if an Actor is stopped and then restarted at a later point (even with the same name/path), the original ActorRef is terminated/dead.
I agree with this and no doubt, Tony, you will too.
As to the default strategy of "restart", I am not sure about this.
Akka has several concepts which we do not have.
One of which is ActorSystem. This is a full collection of system and user actors which is independent of another ActorSystem.
I believe it would be most useful for testing. As we could easily shutdown the previous ActorSystem and start a new one with entirely new state (including the EventSystem/logging).
I have a branch which splits out the core actor functionality (receiver/timers/tasks) from the Object-specific code like SyncCall and friends.
I do think that we need to introduce a new concept ActorContext to encapsulate the notion of a mailbox wrapped up separate to the underlying state introduced by starting an Actor and it running for a moment or 2.
All in all, I think there is a reasonably solid idea of where to go, at least in my head.
Catch you,
Tim