重构 messenger

[dead-horse]

提供方法：

1. broadcast(action, data)：发送给所有的 agent / app 进程（包括自己）
2. sendToApp(action, data): 发送给所有的 app 进程
   • 在 app 调用该方法上会发送给自己和其他的 app 进程
   • 在 agent 上调用该方法会发送给所有的 app 进程
3. sendToAgent(action, data): 发送给 agent 进程
   • 在 app 调用该方法上会发送 agent 进程
   • 在 agent 上调用该方法会发送给 agent 自己
4. sendRandom(action, data):
   • app 上没有该方法（现在 egg 的实现是等同于 sentToAgent）
   • agent 上回随机发送消息给一个 app 进程（由 master 来控制发送给谁）
5. sendTo(pid, action, data): 发送给指定进程

[popomore]

可以分开写下，比如 app 应该没有 sendRandom 方法。

app 调用 sendToApp 会怎么样，sendToAgent 同理

sendTo 可以增强一下，如果是 number 是 pid，都要可以指定 target，比如 app master parent，作为上面方法的基础

[dead-horse]

更新了一下。

sendTo 方法的增强是指可以 sendTo('app', action, data) 还是说在指定 pid 的同事还可以加一个 target 的条件（必须满足 pid 相等，target 相同）？

[popomore]

前一种，process 传的时候有个 to 参数

[dead-horse]

我们需要让应用或者插件开发者感知到 master 和 parent 么？感觉我们现在的这些插件也没出现过向 master 和 parent 发消息的需求啊

[popomore]

更通用一些，send pid 用的也很少

[dead-horse]

这样？

• sendTo('parent/master', action, data)
• sendTo(pid, action, data)

但是 master 和 parent 上其实没有对应的 messenger 实例，应该没法保持这个 action + data 的模型吧？只能 send 一个大的 object 过去？

[popomore]

master 有的，parent 只有 process

[popomore]

sendTo('app/agent/master/parent')

[dead-horse]

parent 是我们不能控制的，mater 其实开发者也无法编写任何逻辑，感觉在暴露给用户的 API 上面增加发给他们的方法只会让使用者更疑惑？

[popomore]

这个还会暴露给插件开发者和核心开发者，比如测试等可能会用到

[dead-horse]

那 sendTo 当做一个内部函数来实现好了？反正应用层不会需要这个方法？

[popomore]

app 进程

• broadcast(action, data) 发送给 agent 和所有 app（包括自己）
• sendToApp(action, data) 发送给所有 app（包括自己）
• sendToAgent(action, data) 发送给 agent
• sendTo(pid, action, data) 指定 pid 发送

agent 进程

• broadcast(action, data) 发送给自己和所有 app
• sendToApp(action, data) 发送给所有 app
• sendToAgent(action, data) 发送给自己
• sendRandom(action, data) 随机发送给一个 app
• sendTo(pid, action, data) 指定 pid 发送

重新整理下 API @dead-horse

[atian25]

@popomore worker 没启动时, agent 发消息, 这个顺便 warning 下

[popomore]

这个不是有另外一个 issue 么

[popomore]

让 master 告诉子进程 pid，然后都 sendTo pid 是不是更好。 暂时不破坏 master 模型了。