Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Kolhoz, Вы писали:
K>> А вообще я не понимаю, к чему это?
E>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Здравствуйте, Cyberax, Вы писали:
>> Ну так неудачный транспорт и неудачный язык выбраны. Только и всего. C>Честно говоря, мне уже давно плевать на чем я пишу.
Конечно плевать. Ты то живой. А вот на чём пишет агент — не плевать. Тупой он очень. Ему что попроще надо.
C> Я могу и на VBA без C>проблем писать. Такое состояние возникает когда знаешь примерно 15-20 C>языков.
Ну я их побольше 20 знаю. Но мне не плевать на чём писать. Я постараюсь выбрать тот язык, который под конкретную задачу наиболее подходит. Случается, что и VBA выбираю. Но для языка общения агентов я точно ничего бейсикоподобного не выберу.
C>Проблемы в том проекте возникали из-за того, что в реальном мире C>существуют разделяемые ресурсы. В частности база данных.
Проблемы возникают если про эти разделяемые ресурсы забывают при проектировании, думая, что "фигня, потом приковыряем".
C>Например, ситуация — клиент делает запрос (асинхронный, синхронный — C>неважно), сервер создает транзакцию, меняет что-то в базе данных и C>отсылает ответ. Вопрос: коммитить ли транзакцию во время отсылки C>сообщений (кстати, сразу же становятся необходимы XA-транзакции)?
Завернуть обработку транзакций в одного атомарного агента, который будет с остальным миром общаться на более высоком уровне. Всего делов. Никто другой соединений иметь не будет. Ресурс перестал быть разделяемым.
C>В некоторых случаях приходилось делать транзакцию длиной в несколько C>запросов (делать statefull-узел), в некоторых случаях надо было чтобы C>клиент подтвердил получение сообщения, и только после этого коммитить C>транзакцию.
Угу. И так можно.
C>В общем, получались _ооочень_ интересные задачи распределенного C>программирования.
Что же тут интересного? Чем БД от любого другого агента отличается? У каждого агента есть состояние, часто — транзакционное, с возможностью отката.
C>И все приходилось делать руками. Так как SOAP — это очень базовая вещь, C>а всякие WS-Transaction и WS-Security — "сынок, это фантастика".
Ну уж на уровне транспорта программировать — и вовсе изврат. Я этого SOAP наелся столько, когда реализацию ebXML (messaging) делал, что больше его видеть не желаю.
>> А это повышает требования к разработчикам компонент. Фтопку. C>Наоборот, понижает. Так как разработчикам не нужно уметь писать C>распределенные алгоритмы — они просто пишут старый добрый синхронный код.
Гы. В моём варианте им вообще не надо распределённые алгоритмы писать. Они делают компоненты, а сшивка делается на стороне.
Здравствуйте, Kisloid, Вы писали:
K>> Чушь говоришь. Подавляющее большинство больших проектов делается в рамках unix way. Я не видел success stories по настоящему крупных систем на DCOM.
K>А причем тут распределенки ?
Мы же про крупные системы говорим, так? Или у нас разные представления о том, что есть крупная система.
K>здесь
смотри последнюю свою фразу. Вообще совутею вам немного оглядываться назад, попытаться посмотреть на себя со стороны. Говорят помогает
И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.
K>> Вот например — с какого перепуга ты меня в пользователи linux записал, а?!? Кто тебе дал такое право? Я хоть словом об этом обмолвился? Наоборот, я постоянно настаиваю на применении концепций unix way под windows. Но ты ж читать не умеешь, куда тебе до таких тонкостей опускаться.
K>А ну от опять пошло поехало: "куда уж тебе, до такого Великого Гуру как Я..."
Вот опять пошло-поехало — ты опять ну ни хрена не понял. Ни единого слова. Скажи, у тебя дислексия, да? Вот расскажи мне, например, как ты понимаешь смысл термина "семантика". В контексте лингвистики. Надо же докопаться до сути — почему ты абсолютно не в состоянии адекватно воспринимать информацию, изложенную на вроде бы родном тебе русском языке.
Здравствуйте, Cyberax, Вы писали:
>> Ты научись сначала понимать, что люди говорят. Ты же русским языком не >> владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и >> подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы >> "презрение к пользователям Windows". C>Было, было. В частности про виндузятников с узким кругозором.
Из контекста было совершенно ясно, что виндузятники — это сторонники genuine windows way. Простых смертных юзеров мы в разговоре вообще не касались. А кругозор ведь и в самом деле узкий — о чём ни начинай разговор, а всё документами закончится. Это, собственно, windows way и есть — всё есть документ, а что не документ, то папочка, и вообще, закройте глаза, дышите глубже, представьте себе тяжелый кондовый такой конторский стол... Представили? Медитируйте на него!
Здравствуйте, Kolhoz, Вы писали:
K> И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.
А чем измеряется крупность системы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?
Давай сравним MSI с распостраннённым на линуксах системой RPM. Сколько у тебя программ под Windows установлено? У меня MSI насчитал 163 пакета. А на Федоре у меня стоит 1079 пакетов (у меня дисковое пространство под линукс ограничено, а то бы ещё больше было). Разница на порядок. Причём подавляющее большинство зависит друг от друга. В MSI системе, в отличие от RPM, все пакеты независимы, и то MSI с трудом ими управляет. Тормоз он завидный. А если бы под Windows каждый кому не лень выпускал пакеты, которые зависят друг от друга (а не копируют каждую библиотеку себе в дирректорию — запусти "dir mfc* /s" у себя в program files), то MSI бы уже давно загнулся. Кто ещё помнит дыру в gdiplus.dll и ту тулзу, которую Microsoft написал, чтобы копии gdiplus.dll на компьютере разыскивать (и даже не исправлять, а просто предупреждать, потому что исправить их было нельзя с практической точки зрения)? Это всё недостатки MSI. А такого понятия, как репозитории под Windows вообще нет.
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Kolhoz, Вы писали:
K>>> А вообще я не понимаю, к чему это?
E>>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Здравствуйте, Kolhoz, Вы писали:
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Видите, с какими противоположными взглядами здесь общаются люди. Если мне школьник скажет, что на небе 102346234846 звезд, то для меня это будет совершенно непроверенная информация. Если же это число скажет профессор-астроном, то я с большой вероятности приму это значение на веру. Хотя бы потому, что я могу сослаться на этого профессора. Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".
Кстати, анекдот в тему:
Беседуют два профессора. Один говорит:
-- Вы представляете, коллега, если сказать кому-нибудь, что на небе 102346234846 звезд, то 99.9% людей в это тут же поверят. А вот стоит повесить на скамейку табличку "Осторожно, окрашено", то все обязательно будут проверять это пальцем.
Извините, если мой вопрос показался вам не корректным. Давно я уже тут, параноя, знаете ли
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote:
> _>Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, > corba, XPCOM, SOAP, всё что угодно. > _>В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то > прилаживаешь, а КОП в Виндоуз ОС — фактически > _>неотъемлимая часть. > Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что > угодно" не приминимы? Если "да", то откровенно говоря закрыдываются > сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), > тогда закрадывается сомнение в честности высказывания.
Применимы. Но это заслуга этих технологий, а не винды.
Ты так и не понял о чём я. Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, хотя не всегда лучшего
качества и не всегда адекватного. Линух — конструктор "собери сам", собираешь по своему вкусу, требованиям, железу.
В винду встроено COM+, и отключить его просто так не получится, тебе оно навязано. А некоторые дистрибы линуха вполне
могут содержать какую-нидь КОП платформу, на которой дистриб построен (та хрень в KDE, например), но это не входит как
неотъемлемая часть в линух вообще.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Kolhoz wrote: > C>Проблемы в том проекте возникали из-за того, что в реальном мире > C>существуют *разделяемые ресурсы*. В частности база данных. > Проблемы возникают если про эти разделяемые ресурсы забывают при > проектировании, думая, что "фигня, потом приковыряем".
Если бы учли их сразу — то не писали бы в виде агентов.
> Завернуть обработку транзакций в одного атомарного агента, который будет > с остальным миром общаться на более высоком уровне. Всего делов. Никто > другой соединений иметь не будет. Ресурс перестал быть разделяемым.
А вот фига. Базу и так уже можно считать агентом, который отвечает на
запросы по некоторому протоколу. Проблема с семантикой работы с данными
в БД.
> Что же тут интересного? Чем БД от любого другого агента отличается? У > каждого агента есть состояние, часто — транзакционное, с возможностью > отката.
Проблема в том, что разные клиенты могут видеть разное состояние БД
в зависимости от своего транзакционного состояния и состояния остальных клиентов. А еще в жестоком реальном мире есть триггеры
в БД, хранимые процедуры и нарушения constraint'ов.
Более того, у БД нет цельного состояния — ее корректно можно
моделировать в агентской парадигме только если считать каждую строку
отдельным агентом.
> C>И все приходилось делать руками. Так как SOAP — это очень базовая вещь, > C>а всякие WS-Transaction и WS-Security — "сынок, это фантастика". > Ну уж на уровне транспорта программировать — и вовсе изврат.
Опять же, работа идет не на уровне транспортов, а на уровне сервисов. Скажем, EJB-контейнер предоставляет управляемым бинам
(bean) контролируемое окружение. Сам контейнер обеспечивает безопасность
(через систему principal'ов), подключает необходимые сервисы, позволяет
декларативно задавать транзакции.
Это все может казаться простым и тривиальным, но корректно это все
реализовать очень непросто.
> C>Наоборот, понижает. Так как разработчикам не нужно уметь писать > C>распределенные алгоритмы — они просто пишут старый добрый синхронный код. > Гы. В моём варианте им вообще не надо распределённые алгоритмы писать. > Они делают компоненты, а сшивка делается на стороне.
Алгоритмы становятся распределенными, если между ними есть разделяемое
состояние (база данных).
Здравствуйте, Дарней, Вы писали:
Д>а поясни мне плиз, какое отношение наличие в Моно поддержки EnterpriseServices имеет к компонентности Моно?
Поясняю — никакого.
Я компонентность Моно не обсуждал — читай внимательнее ту часть сообщения
Здравствуйте, kan_izh, Вы писали:
>> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что >> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются >> сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), >> тогда закрадывается сомнение в честности высказывания. _>Применимы.
Значит делаем вывод в нечестности, ну, или хотя бы в ошибочности твоих высказываний.
_> Но это заслуга этих технологий, а не винды.
Что это тебя так перекосило? Уж не угледел ли ты чего остроумного в своих словах?
Уж не заслуга ли Линукс в том, что эти технологии работают и на нем тоже?
_>Ты так и не понял о чём я.
Возможно. Но понял, что суждения твои крейне противоречивы и ошибочны.
_> Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, хотя не всегда лучшего качества и не всегда адекватного. Линух — конструктор "собери сам", собираешь по своему вкусу, требованиям, железу.
Высосанное из пальца утверждение. Если конечно не брать в рассчет, что можно заняться самостятельным потчиньем ядра.
Я имею под Виндовс все то что под Линукс и немного больше. Обратное не верно. А раз так, то все что можно сказать об линуксе можно сказать и о Виндовс.
_>В винду встроено COM+, и отключить его просто так не получится, тебе оно навязано.
Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а, ни даже графической оболочки нет. Так что это твое незнание проблемы говорит. Виндовс на КОМ не основана. Он в ней часто применяется как средство абстракции и компонентизации, но и только.
Ну, и главное. Что собственного плохого в наличии КОМ? Вот его отсуствие является для многих минусом.
_> А некоторые дистрибы линуха вполне _>могут содержать какую-нидь КОП платформу, на которой дистриб построен (та хрень в KDE, например), но это не входит как _>неотъемлемая часть в линух вообще.
И что? Какое это отношение имеет к делу и к откоровенно неверным и мягко говоря лукавым заявлениям сделанным тобой выше?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности). Как правило, такие люди очень не желают рассказывать о том, чем им приходилось заниматься и над чем они работают сейчас.
Вообще это называется апелляцией к опыту. Коя есть некорректный приём и так далее.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Kolhoz, Вы писали:
K>>> А вообще я не понимаю, к чему это?
E>>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
я вот почитал про вашу любовь к категоричности и большой любви к логическим доказательствам, на основе которых, как я понял, сформированы и выстроены в четкие логические цепочки все ваши знания, а доказательства которые у вас получилось доказать...... хм... вобщем мне стало любопытно...
А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы). АХ>>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше. E>>Что? АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.
АХ>Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?
Другой вопрос, зачем тащить семантику и технику вызова функции, когда можно обойтись посылкой сообщения?
АХ>Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось. Современные компонентные модели более универсальны.
Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, как я её понимаю) не так мёртво завязан на синхронность вызовов. Что COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой длительностью, с помощью которых ещё и эмулировать messaging приходится.
Смотри, в чём разница:
RPC (COM, CORBA... главное — procedure call)
A -- call func(...) --> B
<-- return result --
Возвращается результат вызова функции.
В случае долгоиграющей операции на B появляется
ещё один вызов:
A -- get_result(..) --> B
<-- return of get_result() --
Чистый messaging вдвое экономичней:
A -- msg_to_call_func --> B
тишина...
<-- msg_with_result --
Ну и поскольку здесь не притягивается семантика понятия "вызов функции" (имя функции, параметры, результат), то можно обойтись более простыми средствами, не так сильно влияют стереотипы. Или, говоря порезче: меньше лишнего хлама под ногами болтается.
Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это уже требует в обязательном порядке обкладывать их обработкой исключений, с messaging всё проще — мы сразу честно признаёмся себе, что длительность вызова предсказать нельзя и ориентируемся на модель: "ждём сообщение", а не "должно сработать!".
Эмулировать RPC с помощью messaging — запросто (он и так на нём построен ), обратное — уже не так легко (минимум два варианта: polling или callback), плюс обязательная дополнительная загрузка канала связи. В случае callback (для CORBA) ещё нужно вставлять в клиенскую часть сугубо серверные приблуды итэдэ итэпэ. А простой messaging по IP: сокеты плюс простенькая сериализация. Да и то, в случае C можно структуры данных почти без изменений гонять (диспетчеризация только нужна и решение конфликта endian-ов).
Одним словом, messaging — базовый механизм, на нём уже можно сделать всё.
То же самое касается компонентных механизмов. Компоненты без инфраструктуры — нуль без палочки. В случае unix way требования к инфраструктуре упрощаются донельзя: текстовые данные, messaging по каналам связи — и всё. Инфраструктура тут — сам Unix. В случае всяческих CORBA/COM — толстенная управляющая прослойка, которая опять таки лежит поверх базовой инфраструктуры ОС.
АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?
Играючи. Смотря какая игра, на самом деле.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>Я уже давно понял, что делать распределенные или многопоточные системы C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
Угу. Особенно, если не забывать, что потенциально любой "синхронный" вызов по сети может завершиться исключением.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
