K>>> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.

M>>Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений.

K> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так? Почему всё получалось быстрее, надёжнее и эффективнее чем у всяких любителей сначала морду нарисовать, а потом думать, все ли ветки workflow покрыты и не теряется ли состояние при переходе между элементами интерфейса.

Все так. Только в Web'e весь этот workflow вокруг UI и вертится Специфика

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

C>Вот был бы достаточно стандартный и распространенный бинарный объектный
C>RPC-протокол. Так ведь нету

И на фиг не нужен. Имхо, RPC -- это вообще опиум для народа.

>> C>Если под "unix way" понимать создание модульных приложений — то
>> C>естественно. Причем Unix'ом оно не ограничивается
>> Модульном в том смысле, что каждый модуль, это отдельный процесс,
>> взаимодействующий с другими через IPC.
C>А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC.

Так ты же сам знаешь, что такое IPC, так зачем спрашивать?

Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный протокол использовать?

C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы?
C>Реализуем протокол — и вперед.

Вот именно в этом и проблема.

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

C>Вот был бы достаточно стандартный и распространенный бинарный объектный
C>RPC-протокол. Так ведь нету

И не надо такого счастья. Т.к. RPC — это зло. А COM-РПЦ — это двойное зло, неисцельная болезнь, некуоротимый зверь.
У нас расчетный сервер вначале работал через комовский RPC+shared mem. Это был сплошной и жестокий гемморой.
Во первых на сервере приходилось делать дополнительный поток который отслеживал не сдох ли клиент чтобы гасить сервер.
Во вторых танцы с бубном вокруг регистрации комовских компонентов. Какой сервер последний зарегестрировался в реестре тот и запустится — геморой с дебагжной и релизной сборкой.
В третих программирвать крайне неудобно, т.к. вся "крастота" РПЦ-вызовов сводилась на нет обилием костылей без которых никак не обойтись.

В итоге СОМ/RPC отправился в топку, были заюзаны два пайпа и наступила благодать .

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


M>Все так. Только в Web'e весь этот workflow вокруг UI и вертится Специфика

е-а. Workflow всё же первичен. UI рождается уже на основе анализа workflow. Когда это делается в обратном порядке — нежданчики случаются. Ну да вы наверняка в курсе, такие нежданчики в каждом проекте были, после чего всем становилось ясно (задним умом все крепки), что надо было формальнее к проектированию подходить, и дизайнерам покрепче ручки выкручивать.

eao197 wrote:
> C>Вот был бы достаточно стандартный и распространенный бинарный объектный
> C>RPC-протокол. Так ведь нету
> И на фиг не нужен. Имхо, RPC -- это вообще опиум для народа.
Ага, первое правило распределенного программирования — "Do not distribute!".

Но иногда без RPC плохо. А привязки CORBA к C++ — это такое @#$&@#.

> C>А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC.
> Так ты же сам знаешь, что такое IPC, так зачем спрашивать?
Так просто

> Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный
> протокол использовать?
А если нужно передавать сложные объекты? Тогда придется тратить время на
бесполезный парсинг.

> C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы?
> C>*Реализуем протокол — и вперед.*
> Вот именно в этом и проблема.
А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC
плюс в том, что достаточно его реализовать один раз, а потом
использовать.

Kluev wrote:
> C>Вот был бы достаточно стандартный и распространенный бинарный объектный
> C>RPC-протокол. Так ведь нету
> И не надо такого счастья. Т.к. RPC — это зло.
Просто надо уметь его готовить

> А COM-РПЦ — это двойное зло, неисцельная болезнь, некуоротимый зверь.
Ага. Как и все у МС.

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

C>Ага, первое правило распределенного программирования — "Do not distribute!".

В первый раз слышу.

>> Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный
>> протокол использовать?
C>А если нужно передавать сложные объекты? Тогда придется тратить время на
C> бесполезный парсинг.

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

>> C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы?
>> C>*Реализуем протокол — и вперед.*
>> Вот именно в этом и проблема.
C>А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC
C>плюс в том, что достаточно его реализовать один раз, а потом
C>использовать.

Сложный текстовый протокол не обязательно реализовывать в полном объеме. Если мне нужно что-то передать на сервер в HTTP GET, то для этого совсем не обязательно реализовывать весь HTTP.

К тому же тестовые протоколы легче расширяются, чем RPC интерфейсы, поскольку такие расширения можно просто пропускать, если в них не заинтересован.

Ну и кроме того, если текстовый протокол никак не катит, то можно и бинарные протоколы использовать.

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

C>Kluev wrote:
>> C>Вот был бы достаточно стандартный и распространенный бинарный объектный
>> C>RPC-протокол. Так ведь нету
>> И не надо такого счастья. Т.к. RPC — это зло.
C>Просто надо уметь его готовить

Игра не стоит свеч. Полмесяца убил а толку как с козла молока. В то время как IPC на пайпах был сделан за полдня и заработал сразу просто и безотказно как трехлинейная винтовка.

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

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

DK>>У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили
K> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим.
Их >90 процентов от пользователей персональных компьютеров на планете.
Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"

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

K>> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим.
DK>Их >90 процентов от пользователей персональных компьютеров на планете.
DK>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"

Правильно, над еще добавить, что как программисты мы пишем именно для них. Интересно а для кого пишет товарищ колхозник ?
Бесспорно unix очень красивая вещь, только вот зачем одним местом поворачиваются разработчики, для этих 90% обычных пользователей ?
Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ? Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?

Kluev wrote:
> C>Просто надо уметь его готовить
> Игра не стоит свеч. Полмесяца убил а толку как с козла молока.
А ты пытался использовать DCOM? Тогда неудивительно.

С ICE для С++ или RMI в Java все работает за те же полдня.

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

Пайп сдохнет, а ICE/RMI сможет восстановиться.

> Нафига тогда осваивать сложную геморойную технологию, которая легко
> заменяется простой и безгеморойной.
Ключевое слово если. Если можно заменить без излишних проблем —
то так и надо делать.

Kisloid wrote:
> Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ?
> Почему нет нормальной системы установки софта ? Раз линуксоиды такие
> умные, почему им этого не сделать ?
Как раз с системой установки софта — все нормально: "apt-get install
kde-common" и установлена вся KDE, вместе со всем X-серверами

eao197 wrote:
> C>Ага, первое правило распределенного программирования — "Do not
> distribute!".
> В первый раз слышу.
Высказывание Мартина Фаулера: "The first rule of distributed programming
is don't do distributed programming".

> C>А если нужно передавать сложные объекты? Тогда придется тратить время на
> C> бесполезный парсинг.
> Нормальная сериализация делает передачу сложных объектов очень
> тривиальной задачей.
Вот мы и вернулись к RPC.

RPC — это фактически как раз и есть нормальная сериализация объектов и
их посылка по сети (забудем пока про обеспечение безопасности,
восстановлении от сбоев и т.п.).

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

> C>А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC
> C>плюс в том, что достаточно его реализовать *один* раз, а потом
> C>использовать.
> Сложный текстовый протокол не обязательно реализовывать в полном объеме.
> Если мне нужно что-то передать на сервер в HTTP GET, то для этого совсем
> не обязательно реализовывать весь HTTP.
HTTP — это несложный протокол. Я вот на досуге пытаюсь прикрутить
http://www.xref-tech.com/xrefactory/main.html к своей программе — вот
там действительно извращенский протокол.

> К тому же тестовые протоколы легче расширяются, чем RPC интерфейсы,
> поскольку такие расширения можно просто пропускать, если в них не
> заинтересован.
В RPC — аналогично. В правильном RPC.

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

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

C>Высказывание Мартина Фаулера: "The first rule of distributed programming
C>is don't do distributed programming".

Не хорошо пинать классиков, но здесь я с ним не соглашусь

C>RPC — это фактически как раз и есть нормальная сериализация объектов и
C>их посылка по сети (забудем пока про обеспечение безопасности,
C>восстановлении от сбоев и т.п.).

RPC -- это прежде всего эмуляция синхронного вызова.

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

Тоже самое можно сказать и об RPC.

C>В RPC — аналогично. В правильном RPC.

Интересно, вот требуется в некий вызов добавить парочку параметров. Как это сделать в RPC кроме как добавить новый вызов?

>> Ну и кроме того, если текстовый протокол никак не катит, то можно и
>> бинарные протоколы использовать.
C>А какая разница?

С бинарными сложнее работать в том же Ruby.

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

K>>> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал,
K>>> преимущественно под Windows, и ну ни разу не приходилось применять их,
K>>> вендовый стиль мышления. К чему бы это?
C>>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
AB>Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?
K> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.

Т.е. это твоя разработка? Дело в том, что я хочу посмотреть на гуй под винду, к которому не применялся виндовый стиль мышления и, который сделан именно тобой, согласно заявлению. Т.е. цели моего вопроса можно разбить на 3 части:

1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).
2. Хочу оценить сложность создания подобного одним человеком, который говорит, что этот гуй хорош.
3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.

K> Я пока так и не услышал у апологетов объектной компонентности внятных идей о том, как аналогичную мощь и гибкость реализовать их смешными методами.

В данном случае, мой вопрос к теме, наверное, не относится, а выносить его в отдельную ветку не хотелось.

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

>> C>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
>> Я так понимаю, что образец GUI для подражания в количестве "много" нам
>> не покажут?
C>Из своего я могу только скриншоты наделать, а по ним не очень понятно
C>что и как работает.

Меня интересует только "свой", за которым стоит реальный человек, доказывающий точку зрения в данной ветке. Достаточно скриншотов с объяснением своего видения на них.

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

K>Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ? Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?

Удобные системы установки есть в Debian, Gentoo, SuSe. Во Free-ях так же двигаются в сторону удобства не программистов: http://www.pcbsd.org/

eao197 wrote:
> C>Высказывание Мартина Фаулера: "The first rule of distributed programming
> C>is don't do distributed programming".
> Не хорошо пинать классиков, но здесь я с ним не соглашусь
Нет, правило хорошее. Если что-то можно не распределять — то лучше не
распределять.

> C>RPC — это фактически как раз и есть нормальная сериализация объектов и
> C>их посылка по сети (забудем пока про обеспечение безопасности,
> C>восстановлении от сбоев и т.п.).
> RPC -- это прежде всего эмуляция синхронного вызова.
Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного
вызова — лишь один из вариантов.

Не самый лучший, IMHO, так как не учитывает многие проблемы.

> C>Проблема в том, что это может не быть бутылочным горлом, но если вся
> C>система так построена, то она в целом просто может быть медленной.
> Тоже самое можно сказать и об RPC.
Ну да. Отсюда первое правило распределенного программирования.

У RPC плюс в меньшем оверхеде. Например, в Java вызов через RMI в 50
(пятьдесят) раз быстрее того же вызова через SOAP.

> C>В RPC — аналогично. В *правильном* RPC.
> Интересно, вот требуется в некий вызов добавить парочку параметров. Как
> это сделать в RPC кроме как добавить новый вызов?
Добавить новый метод с двумя параметрами А как ты это в С++ делаешь?

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

>> C>Высказывание Мартина Фаулера: "The first rule of distributed programming
>> C>is don't do distributed programming".
>> Не хорошо пинать классиков, но здесь я с ним не соглашусь
C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не
C>распределять.

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

C>Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного
C>вызова — лишь один из вариантов.

Я говорил об RPC именно как о Remote Procedure Call, а call -- это синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста факт распределенности.

>> C>В RPC — аналогично. В *правильном* RPC.
>> Интересно, вот требуется в некий вызов добавить парочку параметров. Как
>> это сделать в RPC кроме как добавить новый вызов?
C>Добавить новый метод с двумя параметрами А как ты это в С++ делаешь?

В том-то и дело, что в C++ я делаю метод, но вынужден оставлять и старый для совместимости. Либо рефакторить код, чтобы убрать использование старого метода. Между тем, если метод изначально имел формат:

void do_something( const params_t & params );

то расширение структуры params_t не будет сказываться на вызовах do_something.

Вот тестовые протоколы, которые должным образом структурируют информацию (как, например, заголовки HTTP, XML, YAML) как раз позволяют использовать подобный прием.
В бинарном формате такие фокусы позволяют проделывать ASN1 представления (ну и моя ObjESSty ). Однако, как я уже говорил, с бинарными данными приходится больше возиться при их портировании на другие языки программирования.

eao197 wrote:
> C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не
> C>распределять.
> Как раз у меня есть противоположный собственный опыт. То, что казалось
> бы, может работать монолитом, выигрывает по некоторым параметрам
> (надежность, масштабируемость) будучи распределенным.
Сравни сложность разработки — распределенные приложения заметно сложнее
отлаживать и писать.

> C>Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного
> C>вызова — лишь один из вариантов.
> Я говорил об RPC именно как о Remote Procedure Call, а call -- это
> синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста
> факт распределенности.
Такой RPC мне самому не нравится — слишком много проблем вызывает.

А вот что-нибудь типа JMS в Java — вполне себе ничего.

> C>Добавить новый метод с двумя параметрами А как ты это в С++ делаешь?
> В том-то и дело, что в C++ я делаю метод, но вынужден оставлять и старый
> для совместимости. Либо рефакторить код, чтобы убрать использование
> старого метода. Между тем, если метод изначально имел формат:
>
> void do_something( const params_t & params );
>
> то расширение структуры params_t не будет сказываться на вызовах
> do_something.
Ну так никто не мешает делать это и в RPC.

> Вот тестовые протоколы, которые должным образом структурируют информацию
> (как, например, заголовки HTTP, XML, YAML) как раз позволяют
> использовать подобный прием.
Просто сам по себе HTTP запрос представляет вызов одного метода примерно
такого типа:

int processData(std::map<std::string,std::string> params,
    std::map<std::string,std::string> &result, std::string &result);