Архитектурное решение: GUI в отдельном процессе

0

0

Начинаем разрабатывать на C++ сложный продукт, моделирующий сложный объект :-). Должен быть насквозь скриптован, часто будет запускаться в пакетном режиме. Не менее часто, однако, будет использоваться GUI. В связи с этим напрашивается решение разделить GUI и функциональность по разным процессам.

Какой механизм IPC для этого лучше использовать? Сокеты смотрятся слишком низкоуровневыми (придется разрабатывать и поддерживать сложный протокол). CORBA выглядит слишком громоздкой...

Ссылка

←

1С

Определение серийного номера HDD

→

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

anonymous
(26.11.04 10:57:03 MSK)

>>CORBA выглядит слишком громоздкой...

Извините, конечно. Это ваше решение выглядит слишком громоздко.

anonymous
(26.11.04 12:21:13 MSK)

Ответ на: комментарий от anonymous 26.11.04 10:57:03 MSK

>а можешь еще память с данными шарить и из гуя ее атачить просто....

Не значит ли это, что расшаренные данные должны быть POD?

hbee ★★★★
(26.11.04 12:22:29 MSK) автор топика

Ссылка

Ответ на: комментарий от anonymous 26.11.04 12:21:13 MSK

> Извините, конечно. Это ваше решение выглядит слишком громоздко.

Да без проблем. Ругайте, чем больше, тем лучше :-).

А почему слишком громоздко? Зачем тащить GUI в пакетную обработку? К тому же, когда главный поток заведомо не является гуишным, интерфейс легче сделать более "отзывчивым". Например, в смысле прогрессбаров с возможностью немедленной отмены. Гарантируется, что GUI не будет "замирать", что бесит пользователей.

hbee ★★★★
(26.11.04 12:26:06 MSK) автор топика

Ссылка

А не проще ли выделить функциональность в отдельную билиотеку и написать два интерфейса - один командная строка, другой GUI.

fghj ★★★★★
(26.11.04 12:52:57 MSK)

Ответ на: комментарий от fghj 26.11.04 12:52:57 MSK

> А не проще ли выделить функциональность в отдельную билиотеку и написать два интерфейса - один командная строка, другой GUI.

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

hbee ★★★★
(26.11.04 13:09:36 MSK) автор топика

Можно попробовать libgconf, в данном случае это то, что надо (IMHO :)

anonymous
(26.11.04 13:40:11 MSK)

Ответ на: комментарий от anonymous 26.11.04 13:40:11 MSK

> Можно попробовать libgconf, в данном случае это то, что надо (IMHO :)

Гм... Погуглил:

libgconf libraries provide the functions necessary to maintain the configuration database.

hbee ★★★★
(26.11.04 13:42:36 MSK) автор топика

Ответ на: комментарий от hbee 26.11.04 13:09:36 MSK

В многопроцессном дизайне потребуется еще более высокая дисциплина для отслеживания асинхронного ввода-вывода. Проблема все равно остается, и решать ее лучше в GUI целиком. Библиотека же будет проще - только reentrancy и thread-safe (что на C++ довольно легко делается, если правильно писать). К тому же, командная строка (посаженная над бибилотекой) будет избавлена от таких проблем.

Хотя, я могу быть не прав.

Ксати, если CORBA не нравится, то можно ведь и просто RPC использовать. В любом случае это зависит от того, какие данные нужно перегонять - если небольшие, лучше RPC/CORBA, большие и структурированные CORBA/XML-RPC, большие и неструктурированные - socket'ы.

anonymous
(26.11.04 14:36:34 MSK)

Сокеты - это УЖЕ слишком высокий уровень. Пайпов достаточно. Протокол сложный сочинять не надо. Их уже есть полно готовых. И XML-ные решения, и Лисповские S-выражения, и просто код на Tcl. Это же блин unixway!

~~flamer~~
(26.11.04 14:40:34 MSK)

Ответ на: комментарий от anonymous 26.11.04 14:36:34 MSK

>В многопроцессном дизайне потребуется еще более высокая дисциплина для отслеживания асинхронного ввода-вывода. Проблема все равно остается, и решать ее лучше в GUI целиком. Библиотека же будет проще - только reentrancy и thread-safe (что на C++ довольно легко делается, если правильно писать). К тому же, командная строка (посаженная над бибилотекой) будет избавлена от таких проблем.

>Ксати, если CORBA не нравится, то можно ведь и просто RPC использовать. В любом случае это зависит от того, какие данные нужно перегонять - если небольшие, лучше RPC/CORBA, большие и структурированные CORBA/XML-RPC, большие и неструктурированные - socket'ы.

Спасибо за информацию к размышлению.

hbee ★★★★
(26.11.04 15:37:40 MSK) автор топика

Ссылка

Ответ на: комментарий от flamer 26.11.04 14:40:34 MSK

> Сокеты - это УЖЕ слишком высокий уровень. Пайпов достаточно. Протокол сложный сочинять не надо. Их уже есть полно готовых. И XML-ные решения, и Лисповские S-выражения, и просто код на Tcl. Это же блин unixway!

Тоже звучит дельно. Спасибо за информацию к размышлению.

hbee ★★★★
(26.11.04 15:38:18 MSK) автор топика

Ответ на: комментарий от hbee 26.11.04 15:38:18 MSK

Вообще, рекомендую посмотреть на любую Tcl-ную морду - они все по примерно одной схеме построены...

~~flamer~~
(26.11.04 15:57:11 MSK)

Ссылка

Ответ на: комментарий от hbee 26.11.04 13:42:36 MSK

>> Можно попробовать libgconf, в данном случае это то, что надо (IMHO :)

>Гм... Погуглил:

>libgconf libraries provide the functions necessary to maintain the >configuration database.

Все правильно, так оно и есть, но только это немного более, чем просто ini-файл переросток. Фоном крутится gconf, который хранит данные и уведомляет интересующихся, когда что либо изменилось. Все это крутится на корбе. Поэтому можно запустить хоть десяток мордочек(или ни одной) для одной и той же программы одновременно. Корбу они запихали глубоко внутрь и ее знание не обязательно.

Кстати, на мордочках можно вообще сэкономить, и пользовать gconf-editor для смены параметров.

anonymous
(28.11.04 16:24:21 MSK)

Ответ на: комментарий от anonymous 28.11.04 16:24:21 MSK

Нужно быть очень злым человеком, чтобы пропагандировать кривулю вроде gconf в то время, когда существуют нормальные решения вроде http://www.cwi.nl/htbin/sen1/twiki/bin/view/SEN1/ToolBus .

anonymous
(29.11.04 00:55:53 MSK)