Здравствуйте, VladD2, Вы писали:
iZEN>>По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms. VD>Источкник новостей, плиз. Или так уж честно и говори "по слухам".
Да у них на сайте чёрным по белому написано. Не могут решить, какую версию библиотеки GTK использовать и
использовать ли её вообще для реализации WinForms. Месяц назад смотрел специально.
VD>>>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
VD>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.
Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows, но в любом случае использование подхода КОП как в Windows тоже не возбраняется.
В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, Cyberax, Вы писали:
>>> В .NET из компонентностей есть только довольно примитивные формы RPC и >>> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более >>> наглядного не прослеживается — нет даже общей идеологии. C>>Назовите НЕпримитивные формы RPC.
K> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. K> У пользователей Схемы или Тикла получается лучше.
Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и асинхронного JMS. Интересно, если они "развлекаются", то как же получается делать кластеры, работающие 24x7 и 24x365 в промышленных системах?
Здравствуйте, iZEN, Вы писали:
VD>>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов. ZEN>Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить. ZEN>В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо. ZEN>Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows,
Вообще в Unix-подобных системах. да.
Такой дизайн, изначально более продуманный чем в Windows.
ZEN> но в любом случае использование подхода КОП как в Windows тоже не возбраняется.
да.
ZEN>В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Да неправда ваша. Множество изначально Unix программ (Perl,Python,TeX,GCC,да и тот же Cygwin...) портировано на Windows и спокойно там шуршат. Кому надо — те пользуются.
Другое дело, я действительно люблю когда все работает out of the box.
Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось
и не люблю по запутанным мануалам изучать значения флагов в командной строке.
Пусть простые задачи будут простыми.
Здравствуйте, FR, Вы писали:
K>>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
FR>Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE.
Не знаю, у меня никаких проблем с WinXP.
Да она и не может быть хуже чем Win2K ибо там ядро оттуда же растет.
Линейка Win9x закончилась на WinME. Все что дальше — отростки NT.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, FR, Вы писали:
K>>>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
FR>>Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE. АХ>Не знаю, у меня никаких проблем с WinXP. АХ>Да она и не может быть хуже чем Win2K ибо там ядро оттуда же растет.
По устойчивости может и есть.
У меня на одном и том же железе win2k практически ни разу ни падал, XP падает примерно раз в месяц — два.
АХ>Линейка Win9x закончилась на WinME. Все что дальше — отростки NT.
Я про что и говорю NT начал портится скоро до уровня 9X дойдет. Вообще я уже побаиваюсь за висту.
Здравствуйте, FR, Вы писали:
FR> FR>Я про что и говорю NT начал портится скоро до уровня 9X дойдет. Вообще я уже побаиваюсь за висту.
Да я думаю ядро там не трогают. Вроде рюшечки eye candy только навешивают (Avalonы там всякие) .
eao197 wrote: > А эти нормальные компонентные модели интероперабельны между собой? > Например, каким образом COM-компонент будет общаться с JavaBean-ом?
Может. См. http://danadler.com/jacob
> Вообще-то параметры функции все равно будут > сериализоваться/десериализоваться. Вопрос в том, насколько приложение > владеет процессом сериализации. И не факт, что при работе с текстовым > протоколом сериализацию/десериализацию придется делать ручками -- все > это может выполняться автоматическими генераторами парсеров (например. > парсинг HTTP в некоторых HTTP-серверах пишется не вручную).
С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно
сразу передавать графы объектов.
> Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и > фильтры -- это всего лишь самый явный пример. Unix way -- это способ > проектирования приложений из отдельных частей, каждая из которых > выполняет конкретную задачу и общается с другими частями по наиболее > простым протоколам.
Нет уж. Способ проектирования приложения из частей — это называется
"здравый смысл"
Unix way — это именно приложения, интероперирующие через
пайпы/файлы/командную строку.
> Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться > вместе со сложностью задачи.
Если под "unix way" понимать создание модульных приложений — то
естественно. Причем Unix'ом оно не ограничивается
> Только вот, если бы вы смогли показать преимущества тех же CORBA, J2EE и > .NET по сравнению с Unix way в области расширяемости протоколов и в > области интероперабильности, то я с удовольствием бы почитал такое > сравнение.
Хорошая идея для статьи, попробую написать.
> А какие игры? 3D shutter, RPG, Real-Time Strategy? > Если я не ошибаюсь, то в 3D shutter-ах, допускающих сетевую игру, как > раз Unix way и использутся (т.е. есть сервер, который отслеживает всех > игроков, а есть клиенты, которые отображают происходящее игрокам).
Ну такими темпами любое клиент-серверное приложение будет Unix-way'ем.
Anton Batenev wrote: > C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? > Я так понимаю, что образец GUI для подражания в количестве "много" нам > не покажут?
Из своего я могу только скриншоты наделать, а по ним не очень понятно
что и как работает.
Здравствуйте, Андрей Хропов, Вы писали:
K>> Какого файла? А если я туда netcat вставил? Или ssh? АХ>И? В чем проблема? АХ>Передайте имя файла netcatу, а он дальше передаст.
Интересно, как бы вы предложили удалять гланды. Я, кажется, заранее догадываюсь.
АХ>то что вы пишете в Unix как АХ>"ls | more" АХ>можно записать как (условно) АХ>"File result = more.Process( ls.Process(input) )". АХ>more и ls некие компоненты.
АХ>Чуть больше слов, но суть та же.
Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например).
K>> Дао Unix way: K>>- на каждую функциональную единицу — отдельный компонент АХ>Правильно — в любой компонентной системе так.
Не в любой. В объектных моделях для этого функциональная единица должна совпадать с объектом. А это не всегда возможно. Скорее, это почти никогда не возможно — объектная иерархия редко совпадает с семантической.
K>>- к компоненту предъявляются требования: K>> * возможность как программного так и интерактивного задействования всех его функций. АХ>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
Не понял вопроса. Легко и непринуждённо обеспечиваем.
K>> * корректное сообщение о любых исключительных ситуациях АХ>Сообщение мало. Надо еще данные не убить по возможности. АХ>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>Я уж не говорю про RAII. А это предполагает ОО.
ОО тут совершенно не при делах...
АХ>Эээ. Вот тут мне видится фундаментальный изъян. АХ>Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате, АХ>в unix way используется наименьший общий знаменатель — простой текст.
Не обязательно. Не нужна совместимость, на самом деле.
АХ>Часто программы работают все же не с простым текстом, а со структурированными данными АХ>(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.
Ну так кто просит использовать простой текст там, где не требуется?
АХ>Вот LaTeX — это Unix way? АХ>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе.
K>> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао. АХ>Имеют свои плюсы, но не универсальны.
Естественно. А Unix way не требует использования обязательно текстовых потоков.
K>> Что же? Объектно-ориентированную религию не предлагать, тошно-с. АХ>Глупости говорите. ОО давно уже само-собой.
К счастью, далеко не везде.
AX> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть. В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне. Тут пока никаких языков нет и не предвидится. Как оно там внутри устроено — не колышет и не рвёт.
Здравствуйте, Mamut, Вы писали:
K>> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.
M>Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений.
А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так? Почему всё получалось быстрее, надёжнее и эффективнее чем у всяких любителей сначала морду нарисовать, а потом думать, все ли ветки workflow покрыты и не теряется ли состояние при переходе между элементами интерфейса.
M> Потому что никого не волнует, как оно там, на сервере, творится. Главное — чтобы результаты были в доступном виде на экране. Но это — частный случай.
Здравствуйте, Anton Batenev, Вы писали:
C>>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
AB>Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?
Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.
Я пока так и не услышал у апологетов объектной компонентности внятных идей о том, как аналогичную мощь и гибкость реализовать их смешными методами.
Здравствуйте, iZEN, Вы писали:
C>>>Назовите НЕпримитивные формы RPC.
K>> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. K>> У пользователей Схемы или Тикла получается лучше. ZEN>Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и асинхронного JMS.
Вы, товарищ, не влезайте в тему которой не понимаете. Я про агентные протоколы говорю. А вы опять со своими примитивными RPC.
ZEN> Интересно, если они "развлекаются", то как же получается делать кластеры, работающие 24x7 и 24x365 в промышленных системах?
Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.
Здравствуйте, Kolhoz, Вы писали:
C>>Назовите НЕпримитивные формы RPC. K> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело.
Любой нормальный протокол RPC (RMI, DCOM, CORBA) может исопльзоваться для агентного программирования. И что дальше?
И чем именно таким развлекаются программисты на Java? SOAPом?
K> У пользователей Схемы или Тикла получается лучше.
Примеры, примеры?
C>>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать C>>своего незнания в обоих предметах? K> Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O
Нет. Покажи мне реализацию или обертку IViewObject в стандартной библиотеке .NET, например.
Может хватит свое незнание демонстировать?
C>>И уж системы багтрекинга и SCM к формату документов не имеют никакого C>>отношения. K> Имеет, имеет. Они должны идеально интегрироваться в документооборот.
Нормальные SCM ортогональны к остальным системам. Знаменитый Unix way в вашем понимании — создание системы из независимых интероперирующих компоненов.
K> Или вы всё ручками делаете? Представляю, какой кошмар и бардак у вас творится. Одна только попытка засунуть вордовый документ в cvs, думаю, будет тем ещё цирком.
SVN и ваши волосы будут мягкими и шелковистыми.
Да, для объединения и диффов Word-документов используются скрипты: http://www.saisse.jp/svn/SandBox/Diff-Scripts/diff-doc.js и http://www.saisse.jp/svn/SandBox/Diff-Scripts/merge-doc.js ,которые прикручены к TortoiseSVN.
K> А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный.
Опять же, к целостности документации автотестер отношения не имеет НИКАКОГО — он работает с номерами ревизий и именами веток. Все что ему нужно знать — это куда пихать отчеты и куда слать нотификации об ошибках.
С багтрекингом и планированием немного сложнее — для планирования используется комбинация Jira/MS-Project, причем Jira мы специально дописали для совместной работы с MS-Project (Да! Работая через COM из Java!).
C>>Ага. Всякой чепухе про Unix way, например. K> Я, в отличии от некоторых, чепуху доказываю, а не ссылаюсь на чьи либо авторитетные мнения.
Покажите, где я ссылался на авторитетное мнение.
K> Как не было? Было. И все были успешно проигнорированы. K> Например, очень смешно замяли тему про ООП в GUI.
То есть? С удовольствием отвечу подробнее, если интересно.
Cyberax wrote: > С багтрекингом и планированием немного сложнее — для планирования > используется комбинация Jira/MS-Project, причем Jira мы специально > дописали для совместной работы с MS-Project (Да! Работая через COM из > Java!).
Кстати, я забыл добавить.
Все проекты у нас управляются через LDAP, так что для создания нового
проекта надо заполнить всего одну форму и будет создано:
1. Нужные почтовые ящики.
2. Структура репозитория.
3. Проекты в Jira/Confluence.
4. Участникам проекта будут предоставлены необходимые права к
репозиторию и файловому хранилищу проекта.
5. Участники будут добавлены в нужные списки рассылки.
6. И т.п.
Здравствуйте, Cyberax, Вы писали:
>> Вообще-то параметры функции все равно будут >> сериализоваться/десериализоваться. Вопрос в том, насколько приложение >> владеет процессом сериализации. И не факт, что при работе с текстовым >> протоколом сериализацию/десериализацию придется делать ручками -- все >> это может выполняться автоматическими генераторами парсеров (например. >> парсинг HTTP в некоторых HTTP-серверах пишется не вручную). C>С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно C>сразу передавать графы объектов.
Которые только COM-ом и .NET-ом будут пониматься. В отличии от тех же XML-RPC или SOAP.
>> Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и >> фильтры -- это всего лишь самый явный пример. Unix way -- это способ >> проектирования приложений из отдельных частей, каждая из которых >> выполняет конкретную задачу и общается с другими частями по наиболее >> простым протоколам. C>Нет уж. Способ проектирования приложения из частей — это называется C>"здравый смысл"
Читая местные сообщения мне кажется, что Unix way -- это здравый смысл в чистом виде. Не даром Реймонд философию Unix характеризует всего одним принципом: KISS.
C>Unix way — это именно приложения, интероперирующие через C>пайпы/файлы/командную строку.
Еще сокеты забыл. И кстати, не знаешь, почему Реймонд приводит в качестве примера PostgreSQL, в котором процессы между собой через сокеты общаются?
>> Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться >> вместе со сложностью задачи. C>Если под "unix way" понимать создание модульных приложений — то C>естественно. Причем Unix'ом оно не ограничивается
Модульном в том смысле, что каждый модуль, это отдельный процесс, взаимодействующий с другими через IPC.
C>Ну такими темпами любое клиент-серверное приложение будет Unix-way'ем.
Если оно будет допускать прозрачную смену клиента/сервера на написанные на совершенно других языках. Например, чтобы к серверу, написанному на C++ и работающему под Windows без проблем подключался Python-овый клиент из-под Solaris-а. Если так, то таки-да, будет Unix way
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Kolhoz wrote: > K>> У пользователей Схемы или Тикла получается лучше. > ZEN>Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и > асинхронного JMS. > Вы, товарищ, не влезайте в тему которой не понимаете. Я про /агентные/ > протоколы говорю. А вы опять со своими примитивными RPC.
Иностранные поисковики на слова "agent protocol" выдают всякую фигню, а
родной ya.ru на "агентный/агентский протокол" выдает, в основном,
рефераты про искусственный интеллект.
Так что прошу примеры агентских протоколов и программ, их использующих.
> Это RPC и к теме не относится. Тем более что у жабистов нет ничего > сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так > что уж как раз кластерами хвастаться — стыдно.
Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для
high-performance computing.
MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava.
Здравствуйте, Cyberax, Вы писали:
C>>>Назовите НЕпримитивные формы RPC. K>> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. C>Любой нормальный протокол RPC (RMI, DCOM, CORBA) может исопльзоваться для агентного программирования. И что дальше?
Опять демагогия. Я с тем же успехом могу сказать, что "любой нормальный сетевой протокол (TCP, UDP, DecNET, IPX) может использоваться для агентного программирования". RPC — это всего лишь носитель, а агентный протокол — гораздо более выского уровня сущность.
C>И чем именно таким развлекаются программисты на Java? SOAPом?
SOAP — это тоже всего лишь носитель. Я про всякие там BOND говорю.
K>> У пользователей Схемы или Тикла получается лучше. C>Примеры, примеры?
Да какие тут примеры — почти *любой* протокол у Лисперов и Схемщиков к агентному сводится. Благодаря наличию eval в языке.
C>>>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать C>>>своего незнания в обоих предметах? K>> Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O C>Нет. Покажи мне реализацию или обертку IViewObject в стандартной библиотеке .NET, например.
Посмотрю.
C>Может хватит свое незнание демонстировать?
Признаю, что мог тут промахнуться.
K>> Имеет, имеет. Они должны идеально интегрироваться в документооборот. C>Нормальные SCM ортогональны к остальным системам. Знаменитый Unix way в вашем понимании — создание системы из независимых интероперирующих компоненов.
thanx, посмотрю.
K>> А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный. C>Опять же, к целостности документации автотестер отношения не имеет НИКАКОГО — он работает с номерами ревизий и именами веток. Все что ему нужно знать — это куда пихать отчеты и куда слать нотификации об ошибках.
Как это никакого? В документации я цветом отмечаю оттестированные и поломанные интерфейсы. И в общей проектной диаграмме, собранной из этой документации — тоже отмечен процент завершенности каждой из компонент и сетепень серьёзности проблем. Ну и количество незакрытых багов в багтрекинге. Всё в одном документе. Который постоянно висит на десктопе. Знаете ли, очень удобно. Ну да любителям ворда не понять, что такое настоящая интеграция.
C>С багтрекингом и планированием немного сложнее — для планирования используется комбинация Jira/MS-Project, причем Jira мы специально дописали для совместной работы с MS-Project (Да! Работая через COM из Java!).
Любите же вы трудности себе создавать...
K>> Как не было? Было. И все были успешно проигнорированы. K>> Например, очень смешно замяли тему про ООП в GUI. C>То есть? С удовольствием отвечу подробнее, если интересно.
Я же предлагал рассмотреть пример Mathematica (точнее mathview). Как аналогичная задача решалась бы в рамках ОО, без всяких unix way-ных приколов вроде DPS?
Здравствуйте, Cyberax, Вы писали:
C>Все проекты у нас управляются через LDAP, так что для создания нового C>проекта надо заполнить всего одну форму и будет создано: C>1. Нужные почтовые ящики. C>2. Структура репозитория. C>3. Проекты в Jira/Confluence. C>4. Участникам проекта будут предоставлены необходимые права к C>репозиторию и файловому хранилищу проекта. C>5. Участники будут добавлены в нужные списки рассылки. C>6. И т.п.
И чем тут COM помогает? У меня аналогичная система работает практически из коробки, из открытых и свободных деталек собранная на коленке, и сотни строк собственного кода написано не было.
eao197 wrote: > C>С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно > C>сразу передавать графы объектов. > Которые только COM-ом и .NET-ом будут пониматься. В отличии от тех же > XML-RPC или SOAP.
Ну а кто говорил, что будет легко?
COM зато поддерживается большим количеством языков, а Java RMI и .NET
могут нормально интероперировать.
Но если нужно писать многоплатформенное распределенное приложение, то
фактически остается CORBA (со всеми ее минусами) и XML-RPC/SOAP (с их
еще большим количеством минусов).
Вот был бы достаточно стандартный и распространенный бинарный объектный
RPC-протокол. Так ведь нету
> C>Нет уж. Способ проектирования приложения из частей — это называется > C>"здравый смысл" > Читая местные сообщения мне кажется, что Unix way -- это здравый смысл в > чистом виде. Не даром Реймонд философию Unix характеризует всего одним > принципом: KISS.
Не отрицаю, Unix сделан очень красиво. Только вот средств Unix'а не
хватает для десктопных приложений.
> C>Unix way — это именно приложения, интероперирующие через > C>пайпы/файлы/командную строку. > Еще сокеты забыл. И кстати, не знаешь, почему Реймонд приводит в > качестве примера PostgreSQL > <http://www.faqs.org/docs/artu/ch07s02.html#id2922148>, в котором > процессы между собой через сокеты общаются?
Это пример модульного проектирования.
Еще пример — Windows NT/2k/XP. Многие функции WinAPI в нем реализованы в
сервере CSRSS.exe, который отделен от пользовательского процесса и от
ядра. Для передачи вызовов используется LPC (Local Procedure Call).
> C>Если под "unix way" понимать создание модульных приложений — то > C>естественно. Причем Unix'ом оно не ограничивается > Модульном в том смысле, что каждый модуль, это отдельный процесс, > взаимодействующий с другими через IPC.
А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC.
> Если оно будет допускать прозрачную смену клиента/сервера на написанные > на совершенно других языках. Например, чтобы к серверу, написанному на > C++ и работающему под Windows без проблем подключался Python-овый клиент > из-под Solaris-а. Если так, то таки-да, будет Unix way
Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы?
Реализуем протокол — и вперед.
Это было давно, примерно полгода назад.
. Даже в скриптовых языках, без которых Unix way никуда 
