Kolhoz wrote:
> Короче, недостатков этой модели я не вижу. Преимуществ — вагон.
Нет недостатков???? Их куча!

1. Невозможность нормального "обратного" общения. Программы в пайпах не
могут нормально передать информацию "выше" по цепочке.
2. Или ограниченность простыми текстовыми данными, или необходмость
парсить данные в каждой программе.
3. Плохая совместимость со структурированными данными.
4. С бинарными данными еще хуже.
И т.п.

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

ZEN>.... Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.

Чооо ????
В WinNT user-land приложение валит систему? Из под ограниченного аккаунта (не админ)?
Ну-ка пример (только без использования эксплоитов, ибо сие и в никсах есть).

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

C>1. Невозможность нормального "обратного" общения. Программы в пайпах не
C>могут нормально передать информацию "выше" по цепочке.

Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе стороны.

C>2. Или ограниченность простыми текстовыми данными, или необходмость
C>парсить данные в каждой программе.

Это ни фига не недостаток. Это огромнейшее преимущество!!!

C>3. Плохая совместимость со структурированными данными.

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

C>4. С бинарными данными еще хуже.

Да? tar -xf — бла-бла-бла | bzip2

Или того лучше, dvgrab — | mpeg2encode ...

C>И т.п.

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

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

ZEN>А кто сказал, что COM и .Net — компонентные технологии?
COM = Component Object Model.

ZEN>Они обе завязаны на реестр и Windows.
COM да, .NET — в принципе нет (реализация от MS — да).
Но при чем здесь компонентность?

ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет,
Извините, .NET — это международный стандарт, который с Windows никак не связан.
В Mono сталкиваются с трудностями в основном при реализации поведения WinForms точно как в Windows, но это уже немного другое.

ZEN> не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
А что компонентность обязательно включает в себя платформонезависимость?
Я здесь этого не нашел.

ZEN>Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
Это было во времена Win9x.
В 2000/XP/Server 2003 все гораздо лучше. Я не помню когда у меня последний раз был BSOD не по причине железа, вышедшего из строя.

Kolhoz wrote:
> C>1. Невозможность нормального "обратного" общения. Программы в пайпах не
> C>могут нормально передать информацию "выше" по цепочке.
> Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе
> стороны.
А все равно. Нет нормального механизма передачи исключительных ситуаций.

> C>2. Или ограниченность простыми текстовыми данными, или необходмость
> C>парсить данные в каждой программе.
> Это ни фига не недостаток. Это огромнейшее преимущество!!!
Недостаток. Кроме простого текста есть:
1. XML
2. JSON
3. Да хотя бы ini-файлы
4. Файлы с многострочными значениями

> C>3. Плохая совместимость со структурированными данными.
> Чушь. Офигенная совместимость — можно хорошие и правильные S-выражения
> гонять, можно глупый попсовый XML, можно любые бинарные форматы — кому
> что в голову взбредёт.
Какие стандартные утилиты догадаются, что последовательность &#3241 (код
вымышлен) — это буква "а"? Правильно, никакие.

Значит надо как-то канонизировать документы, включая в пайпы
дополнительные программы. И прощай простота.

> C>4. С бинарными данными еще хуже.
> Да? tar -xf — бла-бла-бла | bzip2
А как там у нас grep будет работать, например?

Кстати еще минус — отсутствие методов работы с непотоковыми данными. То
есть "cat somefile | rar | mail ..." уже не сделать — так как
rar'у нужен произвольный доступ для создания solid-архивов.

Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
случае в юниксах эта задача не решается).

> Что и т.п.? Вы уж что либо более похожее на недостатки назовите. С
> конкретными примерами применений, где эти недостатки явственно
> проявляются. Не надо одних только голословных заявлений, ок?
Да пожалуйста, сколько угодно.

Мой любимый пример: как мне таблицу с графиками из Calc вставить в
AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
эффективно решать большую часть административных задач. Только
вот пора бы уже что-то новое придумать.

Андрей Хропов wrote:
> ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации
> точка-нет,
> Извините, .NET — это международный стандарт, который с Windows никак не
> связан.
Но тем не менее, единственная приличная его реализация есть только на
Windows. Кроме того, в этот стандарт не входят почти никакие библиотеки.

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

C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

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

Kluev wrote:
> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Порочный подход. В результате получится только глючная помойка, как
> микрософис.
По странному совпадению, МСОффис безглючнее своих конкурентов.

> Каждая программа должна делать свое дело.
Именно. Word редактирует документ, Excel редактирует таблицы и т.п.

> А в третей все должно интегрироватся.
Как?

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

Просто с OLE произошло все то, что происходит с продуктами MS — "хотели
как лучше, а получилось как всегда". Вместо compound documents можно
было бы использовать простые zip-файлы (как в OO), вместо моникеров —
обычные URL. И тогда OLE выглядел бы намного приятнее.

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

>> Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе
>> стороны.
C>А все равно. Нет нормального механизма передачи исключительных ситуаций.

Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не испытывал.

>> C>2. Или ограниченность простыми текстовыми данными, или необходмость
>> C>парсить данные в каждой программе.
>> Это ни фига не недостаток. Это огромнейшее преимущество!!!
C>Недостаток. Кроме простого текста есть:
C>1. XML

Это — простой текст. Только очень дерьмовый простой текст. У меня всегда практически для обмена структурированной информацией S-выражения используются.

C>2. JSON
C>3. Да хотя бы ini-файлы
C>4. Файлы с многострочными значениями

И? Где тут проблемы, а?

C>Какие стандартные утилиты догадаются, что последовательность &#3241 (код
C>вымышлен) — это буква "а"? Правильно, никакие.

Unix-way не завязан на "стандартные" утилиты. Никак.

C>Значит надо как-то канонизировать документы, включая в пайпы
C>дополнительные программы. И прощай простота.

>> C>4. С бинарными данными еще хуже.
>> Да? tar -xf — бла-бла-бла | bzip2
C>А как там у нас grep будет работать, например?

А зачем для бинарных данных grep?

C>Кстати еще минус — отсутствие методов работы с непотоковыми данными. То
C>есть "cat somefile | rar | mail ..." уже не сделать — так как
C>rar'у нужен произвольный доступ для создания solid-архивов.

Ну так убогий rar — не unix way, он просто не вписывается. Любая компонентная система требует от компонентов следования определённой идеологии (и хорошо если идеологии, а не фиксированному API).

C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
C>случае в юниксах эта задача не решается).

ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
силой.

C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.

C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
C>эффективно решать большую часть административных задач. Только
C>вот пора бы уже что-то новое придумать.

Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно сложного GUI. И все эти "объектно-ориентированные" решения из просто рядом не валялись с простым и элегантным решением в стиле unix way.

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

C>По странному совпадению, МСОффис безглючнее своих конкурентов.

Он глючен имманентно, уже на уровне самой идеологии. Как бы чисто идеологию не реализовывали, она останется глючной.

>> Каждая программа должна делать свое дело.
C>Именно. Word редактирует документ, Excel редактирует таблицы и т.п.

И не фиг их смешивать.

Правда, с другой стороны, Unix way ну нисколечко не мешает сделать такой (пусть и совершенно ненужный) GUI. См., к примеру, wxMaxima.

>> А в третей все должно интегрироватся.
C>Как?

См. мой пример.

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

Идиотизм.

C>Просто с OLE произошло все то, что происходит с продуктами MS — "хотели
C>как лучше, а получилось как всегда". Вместо compound documents можно
C>было бы использовать простые zip-файлы (как в OO), вместо моникеров —
C>обычные URL. И тогда OLE выглядел бы намного приятнее.


Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".

Kolhoz wrote:
> C>А все равно. Нет нормального механизма передачи исключительных ситуаций.
> Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не
> испытывал.
Проблема если нужно одновременно два разных потока данных как-то передавать.

> C>Недостаток. Кроме простого текста есть:
> C>1. XML
> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда
> практически для обмена структурированной информацией S-выражения
> используются.
S-выражения — те же яйца, вид в профиль.

Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
узлам с заданым путем, взять у них атрибут, сделать операцию с этим
атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
потом записать его же в этот документ, но по другому пути.

После часа мучений с tee и прочими гадостями — просто взял
ActivePython+MSXML и за 10 минут написал все что нужно.

> C>2. JSON
> C>3. Да хотя бы ini-файлы
> C>4. Файлы с многострочными значениями
> И? Где тут проблемы, а?
Неудобно использовать стандартные утиллиты.

> C>Какие стандартные утилиты догадаются, что последовательность &#3241 (код
> C>вымышлен) — это буква "а"? Правильно, никакие.
> Unix-way не завязан на "стандартные" утилиты. Никак.
Без стандартных утиллит — получается простая идеология использования
соединенных фильтров.

>> > C>4. С бинарными данными еще хуже.
>> > Да? tar -xf — бла-бла-бла | bzip2
> C>А как там у нас grep будет работать, например?
> А зачем для бинарных данных grep?
А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?

> Ну так убогий rar — не unix way, он просто не вписывается. Любая
> компонентная система требует от компонентов следования определённой
> идеологии (и хорошо если идеологии, а не фиксированному API).
Нет. Это убогий unix way — так как RAR поддерживает создание архивов с
кодами коррекции ошибок (если повреждается часть файла — ее можно
восстановить). Но для этого ему нужен произвольный доступ к источнику и
результату.

> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
> C>случае в юниксах эта задача не решается).
> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
> силой.
Покажите мне fseek на named pipe или domain socket.

Можно использовать shmem с некоторыми ограничениями, но все равно не
хватает возможности полноценно реализовать свой файл.

> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".

> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
> одну систему, и, как показывает практика, вендовозные ламеры, любители
> поредактировать табличку в текстовом процессоре, по эффективности работы
> просто рядом не валялись с теми кто пользуется подобной связкой.
Пробовал. ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
один ужас получается.

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

> Пара дней — и идеального полиграфического качества статья готова, с
> идеальными графиками и достоверно проверенным качеством вывода и
> рассчётов.
Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического
качества, так работа идет с электронными копиями (а печатаются они для
отчетности).

> Вордописцы будут с тем же самым возиться не меньше месяца,
> как, опять же, демонстрирует та же самая практика.
Плохие вордописцы. Или они там формулы рисуют?

Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
неудобно как-либо в текстовом виде записывать).

> C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
> C>эффективно решать *большую часть* административных задач. Только
> C>вот пора бы уже что-то новое придумать.
> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно
> сложного GUI.
ROTFL.

Как раз GUI — это идеальный пример для "компонентов" в понимании
COM/.NET/Delphi.

> И все эти "объектно-ориентированные" решения из просто
> рядом не валялись с простым и элегантным решением в стиле unix way.
Вы LOR читаете? Очень фанатичный стиль похож...

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

K> Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".

Коллеги, настоятельная просьба не скатываться на выяснение отношений и на очередной виток священной войны Unix vs Windows. Если есть желание вывалять себя в грязи, то пожалуйста в Священные Войны.

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

C>Андрей Хропов wrote:
>> ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации
>> точка-нет,
>> Извините, .NET — это международный стандарт, который с Windows никак не
>> связан.
C>Но тем не менее, единственная приличная его реализация есть только на
C>Windows. Кроме того, в этот стандарт не входят почти никакие библиотеки.
Ну я соглашусь, но компонентность то заложена в сам стандарт.

DK>Вопрос.
DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS?
Потому что плохо смотришь. Cygwin/X, XWin32, Exceed и еще пачка.

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

K> Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.

Кстати да, после некоторого опыта работы с LaTeX меняется подход к написанию документов. Особенно, когда используешь собственные команды (либо собственные verbatim, или собственные колонтитулы) и одним легким движением руки изменяешь оформление всех однотипных фрагментов во всем документе -- это впечатляет.

Но, нужно отдавать отчет о том, что использование подобных инструментов требует от пользователя более длительного обучения. Имхо, это обучение окупается сторицей, но далеко не все согласны на это пойти (как по объективным, так и по субъективным причинам). Поэтому наезды от сторонников "дружественного к пользователям" подхода к сторонникам "дружественного к специалистам" подхода будут всегда. И будут носить, имхо, скорее эмоциональный, нежели рациональный характер.

Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.

C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
C>эффективно решать большую часть административных задач. Только
C>вот пора бы уже что-то новое придумать.

Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
черти-что еще. Примеры — KDE, KParts.

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


dmz>Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
dmz>Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
dmz>черти-что еще. Примеры — KDE, KParts.

+1
Хотя можно сделать так:

s/CORBA/Ice/g

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

C>Проблема если нужно одновременно два разных потока данных как-то передавать.

???

Ни разу не проблема.

>> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда
>> практически для обмена структурированной информацией S-выражения
>> используются.
C>S-выражения — те же яйца, вид в профиль.

Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код,
не только данные.

C>Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
C>узлам с заданым путем, взять у них атрибут, сделать операцию с этим
C>атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
C>потом записать его же в этот документ, но по другому пути.

И? Где трудности? Вставить в пайплайн xslt кто запретил?

C>После часа мучений с tee и прочими гадостями — просто взял
C>ActivePython+MSXML и за 10 минут написал все что нужно.

И чем же это не unix way?

>> C>2. JSON
>> C>3. Да хотя бы ini-файлы
>> C>4. Файлы с многострочными значениями
>> И? Где тут проблемы, а?
C>Неудобно использовать стандартные утиллиты.

Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня самые "стандартные" — perl и python.

C>Без стандартных утиллит — получается простая идеология использования
C>соединенных фильтров.

Это и есть unix way. Много маленьких уединённых программок с CLI, способных общаться через пайпы И СОКЕТЫ.

>>> > C>4. С бинарными данными еще хуже.
>>> > Да? tar -xf — бла-бла-бла | bzip2
>> C>А как там у нас grep будет работать, например?
>> А зачем для бинарных данных grep?
C>А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?

Ответ не в тему. Зачем для бинарных данных grep? Есть много других полезных утилит.

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

Нужен произвольный доступ — значит, не нужен поток и масштабируемость. Выбирай.

>> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
>> силой.
C>Покажите мне fseek на named pipe или domain socket.

Зачем?

C>Можно использовать shmem с некоторыми ограничениями, но все равно не
C>хватает возможности полноценно реализовать свой файл.

Зачем? Тем более shmem не масштабируется, так что фтопку.

>> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
>> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
>> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
C>Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".

Какие факты? Есть две ущербные программульки, про unix way ничего не знающие — так какое они имеют отношение тогда к обсуждаемой теме?

>> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
>> одну систему, и, как показывает практика, вендовозные ламеры, любители
>> поредактировать табличку в текстовом процессоре, по эффективности работы
>> просто рядом не валялись с теми кто пользуется подобной связкой.
C>Пробовал.

Плохо пробовали. Неумело.

C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
C>один ужас получается.

Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто пишет её в офисах — надо гнать в три шеи, им в IT не место.

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

Ну ну. Не умеете вы этих кошек готовить.

>> Пара дней — и идеального полиграфического качества статья готова, с
>> идеальными графиками и достоверно проверенным качеством вывода и
>> рассчётов.
C>Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического
C>качества, так работа идет с электронными копиями (а печатаются они для
C>отчетности).

Тогда какие на хрен вордоофисы? Это задача для docbook.

>> Вордописцы будут с тем же самым возиться не меньше месяца,
>> как, опять же, демонстрирует та же самая практика.
C>Плохие вордописцы. Или они там формулы рисуют?

Естественно рисуют.

C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
C>неудобно как-либо в текстовом виде записывать).

Удобно, очень удобно. Удобней чем любой визуальный редактор.

Даже диаграммы Фейнмана — и то удобно, куда уж там всякой попсовой химии.

>> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно
>> сложного GUI.
C>ROTFL.

Это вы от незнания.

C>Как раз GUI — это идеальный пример для "компонентов" в понимании
C>COM/.NET/Delphi.

Отвратительный пример.

Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на стороне логики. Другой вариант — сервер, отображающий визуальные компоненты, которые описываются в виде XML или S-выражений.

Всякой дебильной объектщине в GUI и близко места нет. То, что извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не оправдание.

>> И все эти "объектно-ориентированные" решения из просто
>> рядом не валялись с простым и элегантным решением в стиле unix way.
C>Вы LOR читаете? Очень фанатичный стиль похож...

Я ROTFL читаю и смеюсь.

Нет тут фанатизма. Есть знания и опыт, которых нет у вас.

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

E>Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.

Так и я о том же. Виндоводы при упоминании компонентов сразу рюшечки-менюшечки воображают да композитные документы. Чем сразу выдают свой стиль мышления — от формы к содержанию. Доверять таким людям разработку архитектуры сложных систем — самоубийство, они любую архитектуру будут от GUI проектировать. Особенно этим отлечаются дельфины, в них собрана вся квинтэссенция махрового виндуизма.

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

dmz>Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
dmz>Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
dmz>черти-что еще. Примеры — KDE, KParts.

Дык. Но, однако, что характерно — любая, сколь угодно сложная объектная (или ещё какая) компонентная модель влёт реализуется поверх фундаментальной модели unix way. Тогда как обратное неверно.