2011-04-29 152 views
10

我們在Haskell有一個很大的控制檯應用程序,我負責製作跨平臺並添加一個gui。使用ZeroMQ進行跨平臺開發?

的要求是:

  1. 本機作爲-可能的外表和感覺。
  2. 客戶端適用於Windows和Mac OS X,如果可能,Linux。
  3. 沒有單獨的運行時間來安裝。
  4. 沒有必要的網絡通信。 haskell代碼處理非常敏感的信息,無法通過線路傳輸。這真的是這不是一個Web應用程序的唯一原因。

現在,這個問題的真正原因是爲了解釋我目前正在研究的一個解決方案,並徵求我沒有想到的原因,這使得這是一個壞主意。

我的解決方案是一個本地gui。 Windows上的Winforms,Mac OS X上的Cocoa和Linux上的GTK/Glade,它們只是簡單地處理演示文稿。然後,我會在Haskell代碼的頂部編寫一個圖層,將其變爲使用ZeroMQ來處理消息的UI和來自UI的消息的響應者,以及可能來回序列化數據的protobufs。所以本地應用程序將啓動它本身啓動所有魔法發生的守護進程,並且來回發送消息。

除了確保守護進程只接受來自啓動它的應用程序的連接,以及爲高級gui元素(我正在考慮表視圖,單元格等)提供正確數據的挑戰,我沒有看到很多缺點。

我在想什麼,這是一個壞主意?

我或許應該提到,乍看之下,我打算在所有平臺上使用GTK。問題在於,雖然它很接近,並且GTK和Glade支持Haskell很適合使用,但結果看起來並不「正確」。它很接近,但只是微妙的方式不足以讓那些碰巧正在爲這項工作寫檢查的人無法接受這種解決方案。

此外,gui的多平臺問題和多語言問題不是問題,所以我不一定要尋找其他方法來解決這個問題,除非它簡化了與haskell代碼的交互操作。

回答

8

然後,我會寫在Haskell代碼即把它變成 的消息,並從使用ZeroMQ處理 消息UI應答的頂部上的層,也許protobufs用於序列化的數據來回。

我覺得這是合理(客戶端/服務器模型,其中客戶端只是 恰好是本機的外觀正感受桌面應用程序)。 (關於protobufs和JSON,thrift,我沒有強烈的觀點 )。

Haskell zeromq bindings現在也有一些使用 。

我在想什麼,這是不是一個壞主意?

在Windows和Mac上對zeromq進行了很好的測試?這可能是好的,但我會檢查一下 。

的問題是,雖然已經很接近了,而對於 哈斯克爾GTK和Glade的支持是好的工作,結果不看「右」。

integration package幫助 那裏嗎?

-2

所以你不使用web應用程序的原因是因爲haskell程序輸出的敏感性。這就是爲什麼你要發佈同樣敏感的應用程序,在所有客戶端機器上發出未加密的數據?這沒有任何意義。

如果您的應用程序非常敏感,您應該將DEFINITELLY放在服務器上,並儘可能使用最強的TLS

4

這裏有一個有趣的可能性:wai-handler-webkit。它基本上將QtWebkit與Warp Web服務器打包在一起,以使您的Web應用程序可部署。它沒有見過密集使用,從未在Mac上進行過測試,並且在Windows上進行編譯也很棘手,但這是一種相當直接的方法,可讓您使用在Haskell中開發的相當豐富的Web生態系統。

我很可能會在不久的將來對它進行更多的開發,所以如果您有興趣使用它,請告訴我哪些額外的功能會有用,以及如果您可以提供任何幫助尤其是Mac前線。我也不相信我們需要在所有平臺上堅持使用QtWebkit:根據操作系統使用不同的Webkit後端可能更有意義,或者甚至可能使用Gecko或(顫抖)Trident。

+0

我用hack-handler-webkit或類似的東西搞砸了很久。它工作得很好。只要有空閒時間,我一定會研究這個。謝謝(你的)信息! – clintm 2011-05-04 23:07:47

0

我有一些問題得到zeromq與OSX上的哈斯克爾很好(與尋找一個dylib相對於我認爲的「o」問題)。協議緩衝區和haskell似乎工作正常。