使用 ZeroMQ 进行跨平台开发？答案

【问题标题】：Using ZeroMQ for cross platform development?使用 ZeroMQ 进行跨平台开发？
【发布时间】：2011-04-29 16:15:43
【问题描述】：

我们在 Haskell 中有一个大型控制台应用程序，我负责制作跨平台和添加 gui。

要求是：

尽可能原生的外观和感觉。
Windows 和 Mac OS X、Linux 的客户端（如果可能）。
无需安装单独的运行时。
不需要网络通信。 haskell 代码处理无法通过网络传输的非常敏感的信息。这确实是它不是 Web 应用程序的唯一原因。

现在，提出这个问题的真正原因是解释我目前正在研究的一种解决方案，并征求一些我没有想到的原因，这会使这成为一个坏主意。

我的解决方案是原生 gui。 Windows 上的 Winforms、Mac OS X 上的 Cocoa 和 Linux 上的 GTK/Glade，它们只处理演示文稿。然后，我将在 Haskell 代码之上编写一个层，将其变成一个响应者，用于使用 ZeroMQ 处理消息以及可能用于来回序列化数据的 protobufs 来接收来自 UI 的消息。因此，本机应用程序将启动，它本身将启动所有魔法发生的守护进程，并来回发送消息。

除了确保守护进程只接受来自启动它的应用程序的连接，以及为高级 gui 元素（我正在考虑表格视图、单元格等）来回提供正确数据的挑战之外，我没有看到很多缺点。

我没有想到什么让这成为一个坏主意？

我应该提一下，乍一看，我打算在所有平台上使用 GTK。问题是，虽然它很接近，并且 GTK 和 Glade 对 Haskell 的支持很好用，但结果看起来并不“正确”。它很接近，但在微妙的方面不够原生，这使得该解决方案对于碰巧为这项工作编写支票的人来说是不可接受的。

另外，多平台和多语言的 gui 问题不是问题，所以我不一定要寻找其他方法来解决这个问题，除非它简化了与 haskell 代码的互操作相关的一些事情。

【问题讨论】：

标签： user-interface haskell cross-platform zeromq

【解决方案1】：

然后我会在 Haskell 代码之上写一个层，把它变成使用 ZeroMQ 处理 UI 往来消息的响应者消息，也许还有用于来回序列化数据的 protobufs。

我认为这是合理的（客户端/服务器模型，客户端只是恰好是本机外观桌面应用程序）。（我没有强烈的看法关于protobufs与例如JSON，节俭）。

Haskell zeromq bindings 正在获取现在也有些用。

我没有想到什么让这成为一个坏主意？

zeromq 在 Windows 和 Mac 上的测试效果如何？应该没问题，但是我会检查的。

问题在于，虽然它很接近，但 GTK 和 Glade 支持 Haskell 很好用，结果看起来不“正确”。

integration package 有帮助吗那里？

【讨论】：

【解决方案2】：

这是一个有趣的可能性：wai-handler-webkit。它本质上将 QtWebkit 与 Warp Web 服务器打包在一起，以使您的 Web 应用程序可部署。它没有被大量使用，从未在 Mac 上测试过，并且在 Windows 上编译起来很棘手，但它是一种相当直接的方法，可以让您使用在 Haskell 中开发的相当丰富的 Web 生态系统。

我可能会在不久的将来对其进行更多的开发，所以如果您有兴趣使用它，请告诉我哪些额外的功能会有用，以及您是否可以提供任何帮助尤其是 Mac 前端。我也不相信我们需要在所有平台上坚持使用 QtWebkit：根据操作系统使用不同的 Webkit 后端可能更有意义，或者甚至使用 Gecko 或（颤抖）Trident 代替。

【讨论】：

我用 hack-handler-webkit 或类似的东西搞砸了很长一段时间。它工作得很好。一旦我有空闲时间，我一定会研究这个。感谢您的信息！

【解决方案3】：

我在让 zeromq 在 OSX 上与 haskell 配合使用时遇到了一些问题（我认为寻找 dylib 而不是“o”的问题）。不过，协议缓冲区和 haskell 似乎工作正常。

【讨论】：

【解决方案4】：

因此，您不使用 Web 应用程序的原因是因为 haskell 程序输出的敏感性。这就是为什么您要分发相同的敏感应用程序，该应用程序会在所有客户端计算机上喷出未加密的数据？这没有任何意义。

如果您的应用程序很敏感，您绝对应该将其放在服务器上并尽可能使用最强的TLS。

【讨论】：