10

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

要求是：

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

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

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

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

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

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

此外，多平台和多语言的 gui 问题也不是问题，所以我不一定要寻找其他方法来解决该问题，除非它简化了与 haskell 代码的互操作的某些内容。

4

4 回答 4

8

然后，我将在 Haskell 代码之上编写一个层，将其变成一个响应者，用于使用 ZeroMQ 处理消息以及可能用于来回序列化数据的 protobufs 来接收来自 UI 的消息。

我认为这是合理的（客户端/服务器模型，其中客户端恰好是本机外观桌面应用程序）。（我对 protobufs 与 JSON、thrift 的比较没有强烈的看法）。

Haskell zeromq 绑定现在也得到了一些使用。

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

zeromq 在 Windows 和 Mac 上的测试效果如何？这可能很好，但我会检查一下。

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

集成包有帮助吗？

于 2011-04-29T17:28:10.657 回答
4

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

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

于 2011-04-30T17:30:52.893 回答
0

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

于 2011-07-12T10:36:54.410 回答
-1

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

如果您的应用程序是敏感的，您肯定应该将其放在服务器上并使用最强的TLS。

于 2011-04-30T03:48:43.503 回答