Thanks for the feedback Daniel. I will try to explain how I arrived at the
current design.
The one change I might suggest is not to have message delivery not be a
> method on the actor. That is instead of writing "tom.tell('bob', message);"
> it would either 1) use the director "director.tell('bob', message)" or 2)
> have the director return an actor reference (to allow runtime switching
> between local and remote actors) that can then be used to send messages
> "var bobRef = director.getActorRef('bob'); bobRef.tell(message)".
>
I proceeded initially with the ActorRef idea, but its syntax was too heavy
and just felt wrong for Node. It also does not fundamentally change
anything; there is no practical difference between
var ref = director.actorRef('bob');
ref.tell('hi');
and the existing method
actor.tell('bob', 'hi');
You might argue, and I would agree, that Federation does not provide a
complete actor system. A full system involving child-supervision could be
layered on top of Federation, but I also don't see Node developers moving
to the full-fledged actor model.
The current ability to tell any actor to send a message anywhere I find
> makes for code that is harder to follow and test.
>
I agree, but probably for slightly different reasons. I don't think using
actor refs would improve anything. In a system like Akka, *any actor can
still message any other actor,* if it gets ahold of the actor-system object.
I think the real issue is that a network must be easy to mock in test. I
think this mostly depends on how you have coded your application. Try not
to pass the director around, instead create actors in the root file, and
pass created actors into modules as dependencies:
#server.js
var director = require('federation').init().director;
var actorBob = director.createActor('bob');
var actorTom = director.createActor('tom');
require('./mod1').inject(actorTom);
require('./mod2').inject(actorBob);
#mod1.js
module.exports.inject = function(actor){
return new ModuleWithActor(actor);
}
In the above, mod1 and mod2 can communicate, but can also be tested in
isolation. When you're testing mod1 create a mock actor who responds to 'tom'.
If you dislike using the string-literal 'tom' within a module, assign the
name as a property of your actor object:
#server.js
var actorTom = director.createActor('tom');
var actorBob = director.createActor('bob');
actorBob.father = 'tom';
require('./mod1').inject(actorBob);
#mod1.js
module.exports.inject = function(actor){
actor.tell( actor.father, 'I want a new car');
}
I am quite open to extending this idea further.
I would rather build a full actor layer on top vs. changing the
functionality of the current layer. I don't mind re-naming the current
modules to avoid confusion. A full actor layer however would involve a
supervision hierarchy, and I would be hesitant to build such a heavy layer
on top of such an early project.
*tl;dr* Federation is not yet a full-fledged actor network, but intends to
provide a robust foundation for one.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
