Использование ZeroMQ для кроссплатформенной разработки?
У нас есть большое консольное приложение на Haskell, которое мне было поручено создать кросс-платформенный и добавить графический интерфейс.
Требования следующие:
- Внешний вид, максимально приближенный к естественному. .
- Клиенты для Windows и Mac OS X, если возможно, Linux.
- Нет отдельной среды выполнения для установки.
- Нет необходимости в сетевом подключении. Код haskell имеет дело с очень конфиденциальной информацией, которая не может быть передана по сети. Это действительно единственная причина, по которой это не веб-приложение.
Настоящая причина этого вопроса состоит в том, чтобы объяснить одно решение, которое я исследую в данный момент, и запросить причины, о которых я не думаю. сделайте это плохой идеей.
Мое решение - собственный графический интерфейс. Winforms в Windows, Cocoa в Mac OS X и GTK / Glade в Linux, который просто обрабатывает презентацию. Затем я бы написал слой поверх кода Haskell, который превращает его в ответчик для сообщений в пользовательский интерфейс и из него, используя ZeroMQ для обработки сообщений и, возможно, protobufs для сериализации данных туда и обратно. Таким образом, запускается собственное приложение, которое само запускает демон, в котором происходит вся магия, и отправляет сообщения туда и обратно.
Помимо проверки того, что демон принимает соединения только от приложения, которое его запустило, и задачи предоставление правильных данных взад и вперед для продвинутых элементов графического интерфейса (я думаю о табличных представлениях, ячейках и т. д.), я не вижу в этом много недостатков.
О чем я не думаю, что делает это плохой идеей ?
Я, наверное, должен упомянуть, что на первый взгляд я собирался использовать GTK на всех платформах. Проблема в том, что пока оно близко, и с поддержкой GTK и Glade для Haskell приятно работать, результат не выглядит «правильным». Это близко, но просто недостаточно нативно в некоторых тонкостях, что делает это решение неприемлемым для людей, которые пишут чек для этой работы.
Кроме того, проблема нескольких платформ и, следовательно, нескольких языков для графического интерфейса не является проблема, поэтому я не обязательно ищу другие способы решения этой проблемы, если только это не упрощает что-то во взаимодействии с кодом haskell.