一些加强易用性的修改

[hqwrong]

以下所有修改都是兼容的:

1. snaxd增加一个查询当前服务名字的方法

2. snaxd interface 支持定制loader(增加这个功能是因为我需要在加载snax的时候就把服务所在目录加到loader路径里，而不是load完后再加。)

3. 为cslave增加watch方法，这个在正常关闭服务器的时候有用.

4. snax hotfix 递归的patch_func.

比如考虑如下场景:

local lobster

local function bar()
-- ...
    local _ = lobster -- reference lobster here
-- .....
end

function response.foo()
  -- ...
    bar()
    -- ...
end

这里我要热更新bar函数，需要让bar函数join老的lobster,之前那样是办不到的。

[cloudwu]

其它没有意见，但是 "snaxd增加一个查询当前服务名字的方法" 这个特性我认为实现的味道不好，是硬加了一个判断，且是在 dispatcher 这个根分发函数中。

我建议把查询名字放到 system 子类下，和 init 这些同级。修改 snax.interface 的实现，为每个服务默认加上返回名字的接口（同时可以允许用户自己定义这个接口覆盖）。ps. 可能需要调整 snaxd 里面 SERVICE_NAME = snax_name 到 require 之前。

[hqwrong]

按你的意思改好了，增加了一个snax.name()函数，不过实现稍微有点不一样。

因为调用这个函数的场景是拿handle查询name，再snax.bind为一个snax对象，即调用的时候不能通过snax obj 来获取name方法的method id， 为此我新建了snax/sysfunc.lua 的文件。

[cloudwu]

这里直接写 skynet.ret(skynet.pack(SERVICE_NAME)) 就够了啊，不需要生成一个匿名函数再调用一次。

[cloudwu]

从节省开销的角度，这里 sysfunc 只被 snax.name 一个方法调用，应该移到 snax.name 里面去 require 。

[cloudwu]

我明白了，你要的是从一个 handle 不提供 type 的情况下 bind 成一个对象。并不需要查询 name 。所以我建议不要提供 snax.name 方法。直接在 snax.bind 里加这个特性，当 type 为 nil 的时候，向对方查询。

不过，我有一个疑问：如果你不知道对象的 type ，怎么知道该调用什么方法呢？目前并没有提供 enum 所有方法的 api 。

[hqwrong]

我只是调用它的系统方法。

具体应用场景是，我为debug_console增加了一个hotfix命令，接受服务地址和hotfix文件路径。我希望这个命令自己去查询它的name.

[cloudwu]

目前的 sysfunc 的改法是不对的。因为 system 里的字符串和 id 的对应关系是由每个类型自己生成的，并不保证所有服务的对象，相同的 system 方法对应的 id 都是一致的。比如在 snax.hotfix 和 snax.kill 里，就是按类型去取 id 的。

你提到一个独立位置会造成冲突。

我觉得你这个需求更简单的方法是给 launcher.lua 加一个方法，可以获取 handle 对应的启动字符串更好。也就是增加和 function command.LIST() 类似的方法，去取一个特定 handle 的字符串，而不是全部返回。

另外，cslave 的修改是多余的。https://github.com/cloudwu/skynet/wiki/Cluster 见 harbor.link 方法。

[cloudwu]

如果暂时不给 launcher.lua 加指令的话，其实现在你也可以在 debug console 里调用 LIST 取得所有的，然后挑选出对应的服务启动串的，这样就完全不用修改。

btw. 我个人觉得 snax 的封装有点厚重，可以看一下 https://github.com/cloudwu/skynet_sample 这里写的一个跟简单的封装。

[hqwrong]

咦 按照这个写法, system func的id 不应该固定是1-4吗？

	local system = { "init", "exit", "hotfix", "profile"}

	do
		for k, v in ipairs(system) do
			system[v] = k
			func[k] = { k , "system", v }
		end
end

[cloudwu]

不，只是实现成了这样。但并没有做这个约定。所有用到的地方都是按类型去取的。 王泓钦 <notifications@github.com>于2017年2月9日周四 下午2:45写道：

…

咦 按照这个写法, system func的id 不应该固定是1-4吗？ local system = { "init", "exit", "hotfix", "profile"} do for k, v in ipairs(system) do system[v] = k func[k] = { k , "system", v } end end — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#571 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsiMKA70RyEyrRTHsRcMThA_NfLBzOWks5rarYggaJpZM4L6q9K> .

[hqwrong]

因为launcher只记录了同一节点内的服务，如果是要跨节点查询的话，就比较麻烦了。

[cloudwu]

跨节点可以直接发消息给对方的 .launcher 的. 可以给 harbor.queryname(name) 增强，提供多一个参数，查询别的位置的服务名字。 王泓钦 <notifications@github.com>于2017年2月9日周四 下午3:11写道：

…

因为launcher只记录了同一节点内的服务，如果是要跨节点查询的话，就比较麻烦了。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#571 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsiMLj4jHjmwt0UC8ln-Nxp4H7VencWks5rarwygaJpZM4L6q9K> .

[cloudwu]

在现有基础上，如果不做修改，可以在启动时，把自身的 .cslave .launcher 等服务的 address 写到 datacenter 里，这样就可以跨节点做查询。 云风 Cloud Wu <cloudwu@gmail.com>于2017年2月9日周四 下午3:17写道：

…

跨节点可以直接发消息给对方的 .launcher 的. 可以给 harbor.queryname(name) 增强，提供多一个参数，查询别的位置的服务名字。 王泓钦 ***@***.***>于2017年2月9日周四 下午3:11写道： 因为launcher只记录了同一节点内的服务，如果是要跨节点查询的话，就比较麻烦了。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#571 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsiMLj4jHjmwt0UC8ln-Nxp4H7VencWks5rarwygaJpZM4L6q9K> .

[hqwrong]

好的，我把cslave和snax.name的修改去掉了，重新发起了一个pr

#573