@aleksana@bcom.moe @coelacanthus@mastodon.yuuta.moe 我今天才知道windows也有移植的dbus。
不过看起来这两种方法都不是特别成熟（指用的人不多）。因为这个是在生产环境中使用的，所以最后决定用boost asio + unix socket，序列化用现成的json库。

@chn @aleksana KDE 那些应用程序倒是在 Windows 上都用 DBus

@coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe 问一下，dbus有没有什么方法获得对方的用户id？因为要做多用户的支持。
我发现windows上的unix socket似乎没有办法获得客户端的uid。那这个路子就走不通了。

@chn @aleksana Call dbus_message_get_sender() to get the caller's D-Bus id, and then call GetConnectionUnixProcessID to get the pid of the process that sent the message.

@coelacanthus @chn @aleksana 好奇是什么条件要求在 Windows 上做这个……

@ncts@dabr.ca @coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe 一些计算软件只有windows版本，一个windows服务器要很多人一起使用，所以需要一个工具来排队。

@chn @aleksana @ncts 如果是这种场景感觉没必要直接在机制里获取 UID 啊，完全可以在计算请求的包的划个字段声明用户

@coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe @ncts@dabr.ca 但这样的话就留下个安全漏洞（用户可以假装自己是别的用户来执行任意程序）。所以一定要在服务端判断。
如果都走不通的话，我就用文件传递，毕竟文件是肯定有api能拿到所有者的。

@chn @aleksana @ncts 我以为是小组内部使用，那样只需要加 rate limit 防止误操作就可以了

@coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe @ncts@dabr.ca 确实是小组内使用。但是我觉得不能把管理员权限暴露给普通用户。不能假定每个人都有安全意识，甚至有人可能会故意搞破坏。
rate limit 反而是没必要设置的，因为不会导致致命结果（大不了事后把他提交的任务都取消掉），而且会留下证据（很容易知道是谁干的）。