[mdk-re] Re: [mdk-re] Re: [mdk-re] По поводу электронной почты.
Maksim Otstavnov
=?iso-8859-1?q?maksim_=CE=C1_otstavnov=2Ecom?=
Пт Дек 15 20:48:00 MSK 2000
Hello Mikhail,
Wednesday, December 13, 2000, 12:43:42 PM, you wrote:
>> Это серьезная проблема IMHO.
MZ> Семейство Unix тоже пострадало от этого. Видимо, все ОС, разработанные
MZ> достаточно давно, постепенно "обрастают": дешевле ввести несколько новых
MZ> функций, чем все сломать и построить с нуля "дивный новый мир". Где-то это
MZ> делается достаточно разумно, где-то - как менеджер решит ;)
MZ> Unix отцов-основателей был вполне минималистичен. Они, помня об этом,
MZ> теперь разрабатывают Plan 9. Основная проблема, как я ее вижу, в том,
MZ> что слишком многое в распределении функций между приложениями и ядром
MZ> отдано ядру. Сегодняшние программные технологии позволяют переиграть этот
MZ> баланс. Примерами тому Hurd, BeOS и другие.
>> Но, вообще, если я скажу, что, допустим, скриптование в Web - тоже
>> пример _компонентной архитектуры_, кто первый бросит в меня камень?
MZ> Я, с Вашего позволения :) Нет, конечно, динамически генерируемые страницы
MZ> можно рассматривать как результат удаленных вызовов с параметрами, но
MZ> интерфейс HTTP слишком беден для мало-мальски сложных взаимодействий.
MZ> По-настоящему компонентны (т.е. пригодны для многократного использования в
MZ> гетерогенных, распределеных средах) в Web пока только приложения с
MZ> JavaBeans и немногочисленные решения с CORBA и [D]COM.
Я отстаивал несколько другой тезис. Коротко:
1) *NIX изначально компонентна - за счет pipes/named pipes;
2) *NIX распределенно компонентна - с момента sockets;
3) (распределенно-)компонентная архитектура, основанная на этих
механизмах, действительно плохо масштабируется вниз. Но по вполне
определенной причине: в *NIX отсутствует штатный интерпретатор
основного языка (или промежуточного псевдокода);
4) Internet, взятый как "сумма сервисов" - демонстрация всего
вышесказанного;
5) несмотря на указанный недостаток, у этих механизмов есть одно
маленькое преимущество: они _работают_;
6) реальные проблемы возникают не от того, что механизмы плохи, а от
того, что компонентность пытаются "ввести еще раз" после того, как
культура программирования уже загажена идеологией "приложений" (vs
команды/утилиты/сервисы).
Если это звучит слишком абстрактно, приведу пример "правильной" (с
точки зрения изначальных принципов), или, если угодно, "мракобесной"
архитектуры такой тривиальной штуки, как Word-processing:
+--------------------------------------+
| +---------+ +--------+ +-------+ |
| | VISUAL | |PRINTING| |EXPORT/| |
| |RENDERING| | | |IMPORT | |
| +---------+ +--------+ +-------+ |
| |
| +----------+ |
| | NATIVE | |
| | FORMAT | |
| |PROCESSING| |
| +----------+ |
| |
| e v e n t s |
| |
| commands keystrokes clicks scripts |
+--------------------------------------+
Она _тривиальна_ в том смысле, что слепить прототип - нормальная
дипломная работа, не более, нормальный центральный движок - тоже, и
скрин-рендеринг, и принт-рендеринг. Остальное - пачка курсовых работ.
Даже CORBA не нужна, все гораздо проще.
"Разработчик приложений" размышляет совсем по-другому, он исходит из
интерфейса конечного пользователя, и из его первых потребностей.
Получается совсем другая картинка, что-то типа:
+--------------------------------------+
| |
| С К Р Ы Т А Я Ч А С Т Ь |
| |
|======================================|
| М О Н О Л И Т Н О Е |
| П Р И Л О Ж Е Н И Е |
| |
| +----------+ |
| | VISUAL | |
| | RENDERING| |
| +----------+ |
| |
| keystrokes clicks |
+--------------------------------------+
На это тратится полмиллиона человеко-часов, после чего выясняется, что
если консоль прикрутить забыли, то сделать это уже нет никакой
возможности. StarOffice, в лучшем случае.
--
-- M
Подробная информация о списке рассылки community