Выбор кросс-платформенного инструментария GUI для настольных приложений с помощью WebServices

Question

Для текущего проекта мы разрабатываем клиентское настольное приложение, которое анализирует текстовые файлы и интерфейсы с помощью веб-базы данных.

До сих пор мы разделили проект на часть:

(Сторонние программы) -> (Наш Desktop Client) -> (Наш Синтаксическая библиотека # 1 и # 2) -> (наш веб-сервер) -> (Наша библиотека проверки) -> (Наша база данных)

Мы столкнулись с путаницей, когда речь идет о выборе правильного пути (и лучшего языка), чтобы эти части работали вместе.

Результат третьей стороны - это простой текстовый файл, и мы просто разбираем его в формате SQL-esque для вставки в нашу базу данных после проверки того, что числа находятся в определенном диапазоне.

• Первый вопрос, который мы имеем, касается самого языка клиента. Мы планируем писать библиотеки парсеров на C++, поскольку они всего лишь текстовое управление. Наш настольный клиент должен быть кросс-платформенным для Windows и Mac. В настоящее время мы склоняемся к написанию этого на Java с помощью Swing и JNI. Однако мы понимаем, что для Java существует большая ненависть, и нам придется беспокоиться о связке в JRE.

  Является ли Java хорошим выбором в этой ситуации? Наши другие варианты, похоже, пишут это также на C++, используя что-то вроде Qt для графического интерфейса пользователя, или переходя к платформе, и записывая версию Windows в .NET, а затем версию для Mac. Наше сообщество Windows - подавляющее большинство пользователей.

• Наша вторая проблема заключается в подключении этого клиента к нашему веб-серверу. Первоначально мы просто собирались использовать http POST для загрузки файла. Мы могли бы также FTP-файл, который кажется излишним. Мы начали изучать веб-службы, но не были уверены, что веб-служба может обрабатывать большие объемы текстовых данных.

  Есть ли более простой способ сделать это? Все это текст, поэтому нет проблем отправлять их в куски или одну гигантскую строку. Если мы перейдем на веб-сервисный маршрут, это повлияет на выбор языка для настольного клиента?

Существует определенно сотни способов справиться с чем-то подобным, но большинство из этих концепций являются новыми для нас. Любые предложения будут ценны.

Answer 1

Qt - отличный выбор, и поскольку он является родным C++, он будет легко интегрироваться с вашими парсерами. Зачем писать две версии, когда одна версия Qt будет отлично работать на обеих платформах с естественным внешним видом? В зависимости от выбранной вами лицензии вы можете даже статически связать Qt, если вас беспокоит сложность развертывания.

У веб-службы, как правило, не будет проблем с обработкой большого количества текста, и в значительной степени любой язык будет взаимодействовать с ним, легко предполагая базовую функциональность сетевого ввода-вывода. В зависимости от языка вы, вероятно, сможете найти библиотеки, которые выполняют большую часть работы для вас, если предположить, что он еще не поддерживается изначально.

Как вы говорите, существует множество способов сделать то, что вы хотите достичь. Нет правильного или неправильного пути, но, очевидно, некоторые проекты будут лучше соответствовать вашим потребностям.