Еще один способ способ писать приложения клиент-сервер

очередной маразмЪ

- заточка под тулкит

- не тот уровень абстрактции

- нет мета-уровня

так что не годится никуда.

>заточка под тулкит

Надо было под браузер?

приятно конечно видеть, что кто-то что-то делает, но текущее состояние проекта на первый [и второй] взгляд ещё несколько далековато от активного PRа.. :)

// wbr

>Надо было под браузер?

надо было не затачивать - а сделать мета-уровень виджетов и везде б работало при наличии клиента, хоть в gtk+ хоть в ncurces, но лемминги долго старались пейсали пейсали фихню затачивая все под Qt не понимая что это никому не надо.

А что есть "мета-уровень" и что значит "при наличии клиента". И зачем писать еще один клиенn на gtk+ если клиент уже есть?

О! Знакомая вещь :-)
Привет с OSF ;-)

> что есть "мета-уровень" и что значит "при наличии клиента". И зачем писать еще один клиенn на gtk+ если клиент уже есть?

метауровень это когда тебя не волнует какой на клиенте тулкит - ты пишешь в основном только логику - дизигнер морды делает "мета-морду" то есть без всяких там особенных гуевостей - а отрисовкой в том или ином тулките занимается клиент и отрисовывает чем тебе приперло (есил умеет)

а вот зачем писать еще один баян не ясно ...

ААА вот оно что ? :-D

Фигня, использовать ncurses и QT - очень затруднительно.

>метауровень это когда тебя не волнует какой на клиенте тулкит - ты пишешь в основном только логику - дизигнер морды делает "мета-морду" то есть без всяких там особенных гуевостей - а отрисовкой в том или ином тулките занимается клиент и отрисовывает чем тебе приперло (есил умеет)

И получится очередное мета-поделие, которое не позволяет сделать "уточнения" интерфейса.

> а вот зачем писать еще один баян не ясно ...

зачем писать на чём-то кроме qt? не знаю...

:)

>Фигня, использовать ncurses и QT - очень затруднительно.

все можно...

>И получится очередное мета-поделие, которое не позволяет сделать "уточнения" интерфейса.

уточнение это мега_крутаяая_иконка_из_КеДеЕей ? фтопку оно надо

>зачем писать на чём-то кроме qt? не знаю...

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

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

ну почему же? Клиенту гуй нужен а вот серверу он действительно нет.

Бред какой-то, клиент пишут не абы как, а что бы было как в ТЗ!

>я согласен - зачем компутеру ресурсы нужны кроме как на гуй -

на жабке жабить - они очень нужны.

Этой идее 300 лет. Метаязык описания граф. абстракций не будет простым, скорее он будет сложнее поскрипта. И каждый клиент обязан будет имет процессор этого языка, отображающего абстр. понятия на конкретный тулкит. А теперь прикинь насколько просто написать процессор постскрипт->примитивы Xlib.

Ну и где примеры "правильных" клиент-серверов? CORBA, Net? Просвети, примеры в студию, а то ругать все могут. Я вот например на Qt пишу и мне пришлось... я сам придумал как сделать клиент-сервер, красиво и элегантно. Но идея с Glan-ом мне тоже очень нравится. Интересно а Python bindings к нему тоже можно прикрутить?

>ну почему же? Клиенту гуй нужен а вот серверу он действительно нет.

А в моем проекте нужен: у меня нет разницы где клиента запускать - на сервере или на удаленной рабочей станции - нужно и там, и там.

Я хотел написать библиотеку, которая позволила бы программисту писать сервер как обычную графическую программу не загружаясь шаблонами, джава-скриптами, контролем за состояние клиентского браузера, генераторами HTML страниц CORBA вызовами и прочими сложностями. За основу серверного API был взят QT, что позволило писать сервер как самую обычную Qt программу. Я это сделал. Все.

Вот так выглядит фрагмент серверного кода одного примерчика.

GGroupBox *Window::createSecondExclusiveGroup()
{
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;
}



А в результате у клиента появляются кпопочки, менюшки и прочая графическая радость. Если графику хотите генерить откуда-то еще ( из баз, шаблонов) пишите верхний уровень (кому надо). Ну а при программировании сервера автор совершенно свободен. Весь сервер в его распоряжении. Нужна корба, пользуйтесь,нужна база - она локальна. Вот такая реализация. Лемминги ну что с нас взять ? :)))

>А в моем проекте нужен: у меня нет разницы где клиента запускать - на сервере или на удаленной рабочей станции - нужно и там, и там.

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

С Альфексом разговаривать бессмысленно. Он двух операторов связать не может, а всё кого-то учить лезет. Так что оставьте. Пустое это...

>теперь прикинь насколько просто написать процессор постскрипт->примитивы Xlib.

идей много - есть даже реализации - но увы не сильно распространены ...

>идей много - есть даже реализации - но увы не сильно распространены ...

а теперь откинься на спинку стула и подумай - почему?

кто-нибудь пояснить может, нахрена нам этот портабельный network layer нужен, если уже есть один для юникс-систем - Х протокол, для совместимости с оффтопиком? а насколько это нужно? лично я возможность запускать серверную часть под юниксом, а клиента под оффтопом, считаю _иногда_ полезной, но насколько часто это "_иногда_" встречается? обоснуйте плиз.

>>дей много - есть даже реализации - но увы не сильно распространены ...

и почему же такая мегаидея "не сильно" реализована ? Может, потому, что Саныч прав ? И что ты _конретно_ предлагаешь ?

Потому, что в своё время X11 оказался на тогдашнем железе заметно шустрее, чем NeXTstep, хоть и многократно менее удобным в программировании. А теперь уже историческое решение назад не развернёшь.

Потому, что быдла больше, чем людей.

>А теперь прикинь насколько просто написать процессор постскрипт->примитивы Xlib.

Под винды Xlib? Ой, а зачем?

Это - типичное решение "через жопу". С чем, собственно, и поздравляю.

>И что ты _конретно_ предлагаешь ?

конкретно я пока ничего не предлагаю, ибо я этим не занимаюсь, почему я должен что то конкретно предлагать?

>конкретно я пока ничего не предлагаю, ибо я этим не занимаюсь, почему я должен что то конкретно предлагать?

Как грица - слив засчитан :))))

зы. Ты очередной раз всем показал, что ты ламер полный. Не надоело? Лучше перед деффками понтуйся.

Просьба прекратить рассказывать анекдоты..

>зы. Ты очередной раз всем показал, что ты ламер полный. Не надоело? Лучше перед деффками понтуйся.

типичный быдлоответ, в очередной раз показывающий неадекватность анонимусов на ЛОРе.

>Просьба прекратить рассказывать анекдоты..

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

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

для непонятливых - я речь вел о неком протоколе для прорисовки виджетов, причем не важно какого тулкита и прочее. Для особо тупых - ты делаешь мета-морду (или как там модняво - "шаблон") и на уровне - такой то layout - туда то положить кнопульку, туда то положить меню и с сигналами тоже самое, а вот отрисовкой уже занимается клиент, и будет он для gtk+ или для qt или для вейндового тулкита уже тебя не касается. А городить костыли на фреймворк Qt как то не разумно.

Но заметьте - я не начинал спор toolkitA vs toolkitB, как некоторые воспланенные мозги неких ананонимусов и прочих могли бы подумать.

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

>ты сам писал в гтк, куте? знаешь как они отличаются?

gtk+ да gtk_button_* и пошло поехало, оно конечно понятно и хорошо, но увы и ах ... свои недостатки.

>женерик-слой, блин, сдаётся мне, большинство женерик-подходов так и остались в виде абстрактных идей.

см Inferno кстати - немного не то о чем я писал, но по сути ...

alphex_kaanoken респект за трезвый подход к делу - не в обиду автору

автору респект за то, что енто дело есть сегодня и без лишних слов - не в обиду алфексу ;)

Постараюсь еще раз прояснить ситуацию с проектом специально для мега-эксперта alphex_kaanoken. Крайняя занятость дает мне право скопировать одно из моих сообщений, размещенное в более терпимом к "маразматикам" форуме.

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

>>А городить костыли на фреймворк Qt как то не разумно.

"Как то не разумно" - это не аргумент; судя по вашим Skills and Expirience - личные предпочтения. Полагаю, если такое поделие было бы на Gtk+, с вашей стороны слышались бы только возгласы одобрения...

поясняю _ЕЩЕ_ раз особо "понятливым" - тебе я пишу про что? догадался? я тебе пишу про то что программист не должен знать Qt и особенности тулкита любого - ему ж по сути описали что и как должно вводжится и выводится и ВСЕ, он сделал простейший морд (ну или лучше дизигнер морд) - а то через средства какого тулкита на _клиенте_ или _сервере_ оно отображается этим и занимается тот самый протокол о котором я тебе пытаюсь объяснить.

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

>"Как то не разумно" - это не аргумент; судя по вашим Skills and Expirience - личные предпочтения. Полагаю, если такое поделие было бы на Gtk+, с вашей стороны слышались бы только возгласы одобрения...

кстати нет ;) не угадал

2 alphex_kaanoken ** (*) (12.10.2005 21:20:41)

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

это понятно - никто ничего не говорит.

> А городить костыли на фреймворк Qt как то не разумно.

Честно? Это называется изобретением велосипеда. Смотри сам - все уважающие себя тулкиты тянутся к кроссплатформенности, причём, если изначально они были рождены на *nix, где рисовать приходилось самим, то в чужой среде они предпочитают (по понятным причинам) переключаться на нативные.

Что у нас в итоге? Создать "мета-морду", к которой потребуется набор функций (в том или ином виде), для управление и обеспечения взаимосвязи между данными в приложении и вводом-выводом. На целевой системе эта "мета-морда" будет отрисовываться через некоторую библиотеку, которая решит как там выводить виджеты.

Хм... За исключением возможности выбора между Gtk и Qt на *nix и сомнительного удоволствия использования их же на win/mac, я наблюдаю здесь откровенно избыточное звено... :-/

>Я, размышляя над описанными механизмами, понимал все достоинства и недостатки каждого. Я понимал почему...

ACHTUNG!!! Великий мыслитель "Я" все понял!!!

>Обладают ли этой простотой механизмы основанные на HTTP/HTML/JavaScript/Java/Corba? Разумеется нет

не в обиду будет сказано - когда "Я" впервые увидел CORBA, то подумал что это дикая муть разработанная аццким сотоной :)

это прошло уже после первой программки и настройки удаленного клиента

может вы уважаемый kalpa и гений, но не надо из себя изображать истину в последней инстанции ;)

Народ, я вот только одного не понял - если она на Qt, то почему _G_lan? Уж тогда бы честно называли: Qlan. Или даже Klan... ;-)

2 atrus ** (*) (12.10.2005 23:42:41)

Советую обратить внимание на анологию с RFC и на мысль об образовании стандарта, тогда в общих чертах это будет почти кроссплатформенно..

> уточнение это мега_крутаяая_иконка_из_КеДеЕей ? фтопку оно надо

Такое может сказать только человек, никогда не писавший ничего более или менее приличного и юзабильного для клиентской части. И причем здесь KDE? Может тогда перечислить весь софт использующий QT с некоторыми дополнениями стандартной библиотеки?

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

Тогда возьми MK51 и сиди программи. Да еще и ЖКИ экран на халяву считай :)

>>и сомнительного удоволствия использования их же на win/mac

Ну, у Qt под Windows проблем не наблюдалось(все-таки целевая платформа). А как с Gtk - не знаю, его в комм. приложениях мало используют.

> Ну и где примеры "правильных" клиент-серверов?

9P2000 a.k.a Styx a.k.a v9fs ?..