使用ZeroMQ进行跨平台开发？
我们在 Haskell 中有一个大型控制台应用程序，我负责制作跨平台并添加 GUI。
要求是：
- 尽可能原生的外观和感觉。
- 适用于 Windows 和 Mac OS X、Linux（如果可能）的客户端。
- 无需安装单独的运行时。
- 无需网络通信。 Haskell 代码处理无法通过线路传输的非常敏感的信息。这实际上是这不是 Web 应用程序的唯一原因。
现在，这个问题的真正原因是解释我目前正在研究的一个解决方案，并征求我没有想到的原因，这使得这是一个坏主意。
我的解决方案是本地 GUI。 Windows 上的 Winform、Mac OS X 上的 Cocoa 和 Linux 上的 GTK/Glade，它们只是处理演示文稿。然后，我会在 Haskell 代码之上编写一个层，将其转变为 UI 之间的消息响应程序，使用 ZeroMQ 来处理消息，也许还可以使用 protobuf 来来回序列化数据。因此，本机应用程序将启动，它本身会启动守护进程，所有神奇的事情都会发生，并来回发送消息。
除了确保守护进程只接受来自启动它的应用程序的连接，以及为高级 GUI 元素（我正在考虑表格视图、单元格等）来回提供正确数据的挑战之外，我不看到这有很多缺点。
我没有想到什么让这成为一个坏主意？
我可能应该提到，乍一看我打算在所有平台上使用 GTK。问题是，虽然它很接近，并且 GTK 和 Glade 对 Haskell 的支持很好用，但结果看起来并不“正确”。它很接近，但只是在一些微妙的方面不够原生，这使得该解决方案对于碰巧为这项工作写支票的人来说是不可接受的。
另外，多平台的问题以及 gui 的多语言问题并不是问题，所以我不一定要寻找其他方法来解决这个问题，除非它简化了与 haskell 代码的互操作。
We have a large console application in Haskell that I have been charged with making cross platform and adding a gui.
The requirements are:
- Native-as-possible look and feel.
- Clients for Windows and Mac OS X, Linux if possible.
- No separate runtime to install.
- No required network communication. The haskell code deals with very sensitive information that cannot be transmitted over the wire. This is really the only reason this isn't a web application.
Now, the real reason for this question is to explain one solution I'm researching at the moment and to solicit for reasons that I'm not thinking of that make this a bad idea.
My solution is a native gui. Winforms on Windows, Cocoa on Mac OS X, and GTK/Glade on Linux, that simply handles the presentation. Then I would write a layer on top of the Haskell code that turns it into a responder for messages to and from the UI using ZeroMQ to handle the messages and maybe protobufs for serializing the data back and forth. So the native application would start which would itself start the daemon where all of the magic happens, and send messages back and forth.
Aside from making sure that the daemon only accepts connections from the application that started it, and the challenge of providing the right data back and forth for advanced gui elements (I'm thinking table views, cells, etc.), I don't see many downsides to this.
What am I not thinking about that makes this a bad idea?
I should probably mention that at first glance I was going to go with GTK on all platforms. The problem is that, while it's close, and GTK and Glade support for Haskell is nice to work with, the result doesn't look 'right'. It's close, but just not native enough in subtle ways which make that solution unacceptable to the people who happen to be writing the check for this work.
Also, the issue of multiple platforms and thus multiple languages for the gui isn't a problem so I'm not necessarily looking for other ways to solve that problem unless it simplifies something about the interop with the haskell code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为这是合理的（客户端/服务器模型，客户端只需
恰好是一个原生的外观桌面应用程序）。 （我没有强烈的观点
关于 protobufs 与 JSON、thrift 等）。
Haskell Zeromq
绑定 正在获取
有些现在也用了。
Zeromq 在 Windows 和 Mac 上的测试情况如何？可能没问题，但是
我要检查的东西。
集成包有帮助吗
那里？
I think this is reasonable (a client/server model, where the client just
happens to be a native look-n-feel desktop app). (I have no strong view
about protobufs versus e.g. JSON, thrift).
The Haskell zeromq
bindings are getting
some use now, too.
How well tested is zeromq on Windows and Mac? It is probably fine, but
something I'd check.
Does the integration package help
there?
这是一个有趣的可能性：wai-handler-webkit。它本质上是将 QtWebkit 与 Warp Web 服务器打包在一起，以使您的 Web 应用程序可部署。它尚未得到广泛使用，从未在 Mac 上进行过测试，并且在 Windows 上编译也很棘手，但它是一种相当直接的方法，可让您使用在 Haskell 中开发的相当丰富的 Web 生态系统。
我可能会在不久的将来对其进行更多开发，因此，如果您有兴趣使用它，请告诉我哪些额外功能会很有用，以及您是否可以在 Mac 方面提供任何帮助特别的。我也不相信我们需要在所有平台上坚持使用 QtWebkit：根据操作系统使用不同的 Webkit 后端可能更有意义，甚至可能使用 Gecko 或（不寒而栗）Trident 代替。
Here's an interesting possibility: wai-handler-webkit. It essentially packages up QtWebkit with the Warp web server to make your web apps deployable. It hasn't seen intensive use, has never been tested on Mac, and is tricky to compile on Windows, but it's a fairly straight-forward approach that lets you use the fairly rich web ecosystem developing in Haskell.
I'm likely going to be doing more development on it in the near future, so if you have interest in using it, let me know what extra features would be useful, as well as if you could offer any help on the Mac front in particular. I'm also not convinced that we need to stick with QtWebkit on all platforms: it might make more sense to use a different Webkit backend depending on OS, or maybe even using Gecko or (shudder) Trident instead.
我在让 Zeromq 与 OSX 上的 Haskell 配合得很好时遇到了一些问题（我认为寻找 dylib 而不是“o”时出现问题）。不过，协议缓冲区和 haskell 似乎工作得很好。
I've had some problems getting zeromq to play nice with haskell on OSX (problems with looking for a dylib as opposed to an "o" I think). Protocol buffers and haskell seems to work fine though.
因此，您不使用 Web 应用程序的原因是因为 haskell 程序输出的敏感性。这就是为什么您要分发相同的敏感应用程序，该应用程序会在所有客户端计算机上泄露未加密的数据？这没有任何意义。
如果您的应用程序是敏感的，您绝对应该将其放在服务器上并使用尽可能最强的 TLS。
So your reason not to use a web application is because of sensitive nature of haskell program's output. And THAT's why you are distributing that same sensitive application that spews out unencrypted data on ALL client machines ? That does not make any sense.
If your application is sensitive you DEFINITELLY should put it on server and utilize strongest possible TLS.