Показывали мне на днях эту штуку. Очень удобная вещь для построения распределенных приложений, web based приложений на мой взгляд...
Клиент — чтото типа эээ так сказать браузера.
Сервер — некоторое приложение написаное при помощи библиотеки Glan.
Суть — GUI имеем на локальной машине, а выполняется оно на серваке.
Основано это дело на QT. Написать программу подэто дело грубо говоря это сменить Q на G в именах qt классов... Довально легко короче.
Работает шустро, траффик шифруется и гзипуется
Просто пишите Ваш сервер используя стилистику и методологию QT и забудьте о клиенте. Библиотека Glan и Glan-Клиент сделает все остальное.
Тут сайт об этом деле, правда версия там лежит довольно старая и мало чего почитать вобще...

Здравствуйте, Sheridan, Вы писали:

S>Тут сайт об этом деле, правда версия там лежит довольно старая и мало чего почитать вобще...

да, действительно нечего посмотреть, почитать, только скачать

Здравствуйте, ilnar, Вы писали:

I>да, действительно нечего посмотреть, почитать, только скачать

Автор обещает скоро сделать документацию...
Я видел как оно работает... Очень многообещающий проект.

Проект «Glan» (GLobal Application Network)

Требования делового мира к современным системам постоянно растут. Все острее ощущается потребность в сетевых решениях с развитым графическим интерфейсом. Существует несколько описанных и ставших популярными подходов к решению этой задачи однако они имеют как свои достоинства, так и недостатки. Опираясь на существующий опыт и требования заказчика автором была предпринята попытка создать максимально простой, комфортный, понятный, не требующий дополнительного изучения способ разработки сетевых приложений с развитым пользовательским интерфейсом. К проекту предъявлялись следующие требования
* Максимальная простота разработки приложения.
o Программист должен быть знаком с принципами построения пользовательского интерфейса.
o Программист должен создавать приложение как обыкновенную несетевую графическую программу.
o Программиста нельзя обременять сложными дополнительными программными интерфейсами.
o Программист не должен быть загружен дополнительным знанием о способах организации взаимодействия между клиентом и сервером.
o Программист не должен думать о клиентской стороне.
o Программист не должен думать о сетевой стороне создаваемого решения.
* Нетребовательность к телекоммуникационным ресурсам
o Взаимодействие клиента и сервера должно осуществляться на минимальных скоростях.
* «Тонкий клиент» как средство взаимодействия клиента с сервером.
o Клиентская часть тандема должна быть минимальна по размеру и нетребовательна к ресурсам.
o Клиент должен быть кроссплатформенным и работать на основных коммерчески эксплуатируемых платформах.
o Пользователь «тонкого клиента», взаимодействующего с сервером не должен видеть разницу между обычным локальным приложение и приложением Glan.
В ходе решения поставленных задач разрабатывается инструмент, который был назван Glan (Global Application Network). Инструмент представляет собой тандем библиотеки разработки серверов приложений и «тонкого клиента».
Библиотека предоставляет разработчику возможность не задумываться о всех сложностях создания сетевых приложений, но полностью сконцентрироваться на создании программы. В распоряжение разработчика поступает развитый набор средств, которые хорошо знакомы разработчику пользовательского интерфейса. Программист может свободно оперировать такими понятиями как «окно», «фрейм», «меню», «кнопка» и прочими хорошо известными инструментами из арсенала разработчика интерфейса. Кроссплатформенность достигается посредством использования хорошо известной библиотеки Qt, разработчиком которой является компания TrollTech. Именование классов, параметров функций и внутренних структур библиотеки Glan, максимально идентично именованию в Qt. В этом разработчики Glan усматривают дополнительные преимущества, позволяющие большому пласту программистов, использующих Qt в своей практике, легко адаптироваться в классах Glan. Более того, появляется возможность трансформировать существующие Qt приложения в сетевые. Максимально комфортный способ разработки позволяет полностью перенести нагрузку на сторону сервера,
предоставив "клиенту" только интерфейсные функции. За интерфейсной оберткой библиотеки Glan скрывается механизм рационального транспорта информации и данных между клиентом и сервером. Оптимизационным ключом стали алгоритмы сборки запросов в пакеты и передача подготовленных данных в сжатом виде. Получаемый на стороне клиента комфорт от использование сетевой «Glan программы» максимально идентичен комфорту от работы с обычной локальной программой. Пользователь получает интерфейс к которому он привык во всем его функциональном многообразии и не испытывает известного дискомфорта от работы с интерфейсами основанными на HTML браузерах. Описанные возможности дают разработчикам основание позиционировать Glan как инструмент создания Интернет-приложений с развитым пользовательским интерфейсом. А простота программирования сервера ( идентичная с принципами программирования обычного графического приложения ) дает разработчику дополнительные возможности создания современных сетевых приложений.
© Copyright Олег Шальнев

Уже можно посмотреть — пощупать...
здесь
Под виндовз: включая Qt и без Qt
Под линукс можно собрать из исходников
Тестовый сервер: 85.192.32.124 — доступны 2 тестовых приложения — на 15002 порту и на 15003 порту
Прошу обратить внимание что прога выполняется "там", т.е. на сервере — у вас только интерфейс.

Я так понял дотнету это неинтересно...
Ну ясен пень дотнет то кутэ неподдерживает...

Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

Здравствуйте, Mamut, Вы писали:

M>Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

4й. Чел долго мучался но переделал с 3 на 4...

M>>Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

S>4й. Чел долго мучался но переделал с 3 на 4...

Ндаа. Ему памятник надо ставить. Если в 3-ем можно было на всю катушку использовать Qwidgetfactory, то сейчас я даже не представляю...

Здравствуйте, Mamut, Вы писали:

M>Ндаа. Ему памятник надо ставить. Если в 3-ем можно было на всю катушку использовать Qwidgetfactory, то сейчас я даже не представляю...

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

Очень круто.
Хотелось бы задать только один вопрос — а зачем нужна такая вредная весч? =)

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

При жизни хорошей в распределенном приложении выполняется распределение нагрузки. В пользу клиента
Т.е. времена, когда вычисления нужно было перекладывать на плечи серверов были. Но они как бы уже прошли. Сейчас соотношение мощностей среднего сервера и среднего клиента гораздо меньше, чем количество клиентов, которое на этот сервер приходится.

Так что применение такого, безусловно очень любопытного, образца высокой программистской мысли, лично мне представляется достаточно ограниченным.Особенно с учетом проработанности механизмов/архитектур для построения приложений полноценных.

Я не прав?

Здравствуйте, mrozov, Вы писали:

M>Я не прав?

В принципе правы. Но возьмем приложения типа бухгалтерии, банковского опердня, банк-клиент в конце концов... Тут имхо скрипты на стороне пользователя даже опасны...

S> Но возьмем приложения типа бухгалтерии, банковского опердня, банк-клиент в конце концов... Тут имхо скрипты на стороне пользователя даже опасны...

Ну может быть. Но разве в них не возникает проблемы с масштабируемостью решения? А тут мы вдобавок будем иметь сетевые обращения (и лаги) на каждое действие...
Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".

Не настолько уж страшен черт распределенных приложений. Имхо.

Ладно, проехали.

Здравствуйте, mrozov, Вы писали:

M>Ну может быть. Но разве в них не возникает проблемы с масштабируемостью решения? А тут мы вдобавок будем иметь сетевые обращения (и лаги) на каждое действие...
Траффик довольно маленький. Отчасти потому что гзипуется...

M>Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".
Да, перекрываются. Но.
1. Эти сервисы стоят денег, причем немалых.
2. Для терминальных серверов можности нужны побольше, потому как помимо самих копий приложения им нужно еще тянуть на себе "терминальную оболочку" так сказать...
3. ТС насколько я помню тягают по сети графику, Глан же действует подругому. Можно считать глан либой для софта со срезаным интерфейсом. То есть программа пашет "там", интерфейс "здесь"...

M>Не настолько уж страшен черт распределенных приложений. Имхо.
Еще менее страшен. С этой либой можно легко переделать уже готовое приложение (конечно, написаное на кутэ) в распределенное. Достаточно поменять в именах кутэ классов Q на G и еще чтото помелочам...

M>Ладно, проехали.
Вы довольно верные вопроосы задаете. Задавайте еще

И еще.
Представим себе браузер на основе Глана... Вот как эксплорер тотже... Я когда представил — проникся... Разработка проектов правда тяжеловата, но представьте что можно вытворять! Форумы, электронные магазины, поисковики теже...

Здравствуйте, mrozov, Вы писали:

M>Очень круто.
M>Хотелось бы задать только один вопрос — а зачем нужна такая вредная весч? =)
Ну почему же вредная.
M>Поясню — даже в web-приложениях как правило на стороне клиента выполняется хоть какая-то работа. Скриптами.
M>Скрипты эти иногда приходится делать опциональными (не от хорошей жизни), но это не делает их бесполезными.Ибо они существенно сокращают количество ненужных сетевых запросов.

M>При жизни хорошей в распределенном приложении выполняется распределение нагрузки. В пользу клиента
M>Т.е. времена, когда вычисления нужно было перекладывать на плечи серверов были. Но они как бы уже прошли. Сейчас соотношение мощностей среднего сервера и среднего клиента гораздо меньше, чем количество клиентов, которое на этот сервер приходится.

M>Так что применение такого, безусловно очень любопытного, образца высокой программистской мысли, лично мне представляется достаточно ограниченным.Особенно с учетом проработанности механизмов/архитектур для построения приложений полноценных.

M>Я не прав?

Мне думается что не совсем.
Ситуация в мире клиент-серверных приложений не столь однозначна. Достаточно хотя бы
вспомнить о распространенности терминальных решений. О "тонких компьютера" за $200 и прочее.
Тут, как Вы понимаете, разговор о "распределенности" вообще возможен только на стороне сервера.
Если говорить коротко, существует несколько способов создавать клиент-серверные приложения.
1) классическая 2-х звенка ( толстый клиент — база данных)
2) 2-х звенка, прикидывающаяся 3-х звенкой. (терминальный клиент-терминальный сервер-толстый клиент- база данных)
3) 3-х звенка ("тонкий клиент" — сервер — база данных)
в данном случае под "тонким клиентом" понимается как HTML браузер, так и специализированные
приложения, которые работают с графикой.
4) средства построения клиент-сервер на основе технологий объектного брокеринга.
Вот собственно и все. Какое из направлений Вы считаете "архитектурой для построения полноценных
приложений" или "проработанные механизмы" мне непонятно.
Я, размышляя над описанными механизмами, понимал все достоинства и недостатки каждого. Я понимал
почему так популярны "терминальные решения". А популярны они именно по причине простоты создания
серверного программного обеспечения. Программист просто вооружаясь обычной графической библиотекой
и средствами доступа к базе данных, создает приложение. Терминальные средства ( млм средства базы данных) максируют все остальное. Ключевое слово — простота разработки.
Обладают ли этой простотой "проработанные механизмы" основанные на HTTP/HTML/JavaScript/Java/Corba?
Разумеется нет. Для описания простейших интерфейсов Вам приходится работать с кучей файлов и данных, логика размазывается по телу приложения. Возможно кому-то этот подход кажется разумным.
Мне нет. И таких людей давольно много, если принять во внимание обилие средств, делающих,
средствами Java, программирование в этой стилистике более похожее на человеческое. Народ, живущий
в мире Java, делает свою жизнь проще камуфлируя всю известную сложность обрастая тоннами кода и
заметно утяжеляя решение. Мне показалось, что мой подход возможен и имеет место быть и он не
может быть назван только "образцом программистской мысли" посколько имеет рациональные зерна.
В самом деле, разве не приятно работать над серверной частью системы как с совершенно обычным
StandAlone приложением не думая ни о сервантах, скриптах, шаблонах, генерациях страниц,
контрольных точках ( для понимания где находится клиент) а просто писать хорошо знакомый текст.
Вот такой например


TransportPacket Packet;
GGroupBox *groupBox = new GGroupBox(tr("E&xclusive Radio Buttons"), this);
groupBox->setCheckable(true);
groupBox->setChecked(false);

GRadioButton *radio1 = new GRadioButton(tr("Rad&io button 1"), this);
GRadioButton *radio2 = new GRadioButton(tr("Radi&o button 2"), this);
GRadioButton *radio3 = new GRadioButton(tr("Radio &button 3"), this);
radio1->setChecked(true);

GCheckBox *checkBox = new GCheckBox(tr("Ind&ependent checkbox"), this);
checkBox->setChecked(true);

GVBoxLayout *vbox = new GVBoxLayout;
vbox->addWidget(radio1);
vbox->addWidget(radio2);
vbox->addWidget(radio3);
vbox->addWidget(checkBox);
vbox->addStretch(1);
groupBox->setLayout(vbox);

return groupBox;

Это процедура, создающая на стороне клиента группу кнопок. Кто писал на Qt понимает насколько
текст идентичен классическому. На самом деле только одна буква в названии классов изменена.
Ну а уж если Вам нужны всякие тонкости, базы данности и распределенности. Сервер в полном Вашем
распоряжении.
Да, еще о программистской мысли. Аналогичные средства есть в мире Java, только очень медленные.

Здравствуйте, mrozov, Вы писали:

M>Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".

Ну разве подобные решение не ресурсоемки? Сколько экземпляров таких "тучных" приложений
Вы можете запустить на сторое сервера, таская за собой весь груз не нужно на этом самом сервере
графики?
А толщина серверного канала. Мне многие говорят, что де нормально все работает на 56К.
Прикиньте сколько будет по 56К в обычном 2М канале? Далеко не все конторы могут купить толстые каналы а возможность обслужить число клиентов более 30 есть.

Прошу любить и жаловать — kalpa, автор идеи и проекта Glan.

Я имею дело с автором? Вау!

Довод комрада Sheridan по поводу легкости превращения простого приложения в распределенное принимается без доп. вопросов. Действительно — впечатляет.

По поводу всего остального. В описанном подходе меня смущают:
— плохая масштабируемость
— лишние обращения к серверу

Разработку UI на основе html/dhtml считаю стандартным и прекрасно проработанным решением. Раньше, кстати, относился к нему снисходительно. В последние годы — с уважением.

Опять же — не вижу проблемы в проведении посередине приложения водораздела в виде удаленного фасада. Возможно — просто привык, согласен.
И все же — это накладывает не так уж и много ограничений. В каком-то смысле даже способствует четкому разделению логики на слои.
RMI/.net remoting позволяют работать с удаленными подсистемами "даже самым маленьким".

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

Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".

Здравствуйте, mrozov, Вы писали:

M>По поводу всего остального. В описанном подходе меня смущают:
M> — плохая масштабируемость
Это как посмотреть и что понимать под масштабируемостью. Если возможность писать серверы для
платформы Windows то она есть. В прошлой версии, дык серверы нативно в виндузе собирались.
Сейчас, правда, опять вернулся к fork ( все страхи, страхи )
M> — лишние обращения к серверу
помилосердствуйте. Уж как много трафика гоняет HTML решения. А уж если разработчик использует всякие слои Уууух.

M>Разработку UI на основе html/dhtml считаю стандартным и прекрасно проработанным решением. Раньше, кстати, относился к нему снисходительно. В последние годы — с уважением.
Я никоим образом не хочу уничижить достоинства этого подхода. Просто мне он кажется несколько
вычурным. Да и возможности создания развитого пользовательского интерфейса остаются ограниченными,
хотя последнее время много сделано в этом направлении. А используя решение Glan интерфейс получается неотличимый от обыкновенного и разработчик ничем не ограничен.
Я хочу упростить жизнь свою ну и той части программерского населения, который заинтересуется этим подходом.

M>RMI/.net remoting позволяют работать с удаленными подсистемами "даже самым маленьким".
Согласен, но каждый вызов удаленной процедуры суть маленький пакет, который был подготовлен и отправлен средствами библиотеки. Когда Вы пользуетесь этими средствами разумно (редко) например запрашивая какой-нибудь расчет на соседнем сервере это нормальное решение, но когда Вам надо в маленькой процедурке (см пример выше) несколько десятков раз вызвать удаленную процедуру, Вашей программе это вряд ли понравится, да и TCP/IP стек будет не в восторге от обилия пакетом размером в 200 байт.

M>Мне кажется, что данная система будет провоцировать на создание неоптимальных решений.
Мне думается иначе. Впрочем, об оптимальности надо думать пр разработке любых систем.

M>Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".
Рад что смог почь Вам разобраться. Кстати, есть демострационный сервер на которм запущены пара
демок. Они помогут более полно представить себе суть вопроса.

Здравствуйте, kalpa, Вы писали:

M>>Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".
K>Рад что смог почь Вам разобраться. Кстати, есть демострационный сервер на которм запущены пара
K>демок. Они помогут более полно представить себе суть вопроса.

kalpa про Glan — доступны тестовые приложения

Автор: Sheridan
Дата: 10.10.05