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

Question

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

Пока что мы разбили проект на части:

(Сторонняя программа) -> (Наш клиент для настольных ПК) -> (Наша библиотека синтаксического анализа # 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, если вы обеспокоены сложностью развертывания.

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

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