|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 25 Jul 2002 22:07:17
To : Denis Smirnov
Subject : Re: Network file system
--------------------------------------------------------------------------------
Denis Smirnov <mithraen@freesource.info> wrote:
DS> Почему-то у меня это очень сильно ассоциируется с DCOM. И
Hу, конкретный способ взаимодействия между компонентами - DCOM,
CORBA, сокеты, ICCCM - это не суть важно.
DS> основной проблемой я считаю конкретно здесь то, что
DS> почтовый клиент должен как-то узнать о том, что существует
DS> адресная книга ICQ.
Э-э нет. Существует объект "Адресная книга" в смысле такая маленькая
базка данных по персонам и организациям. Она была в соответствии с тобой же
предложенным принципом декомпозиции aka unix way оторвана от того
самого почтового клиента (покажите мне почтового клиента, где бы не было
базы алиасов. Даже в mailx она есть). Только ее потом пришлось научить
что разным приложениям может требоваться разная информация о персонах,
поэтому они вправе добавлять туда дополнительные поля.
Естественно, что в соответствии с тем же самым принципом декомпозиции,
объект ICQ-клиент не ведет своей собственной адресной книги, а
использует общесистемную. То есть ту же самую, что и почтовый клиент.
Он нуждается в таком свойстве персоны как UIN. А есть еще
компонента-напоминалка о событиях, аналог старого доброго BSD-шного
calendar. Она пользуется той же самой адресной книгой на предмет узнать,
не предстоит ли день рождения кого-то из знакомых.
DS>>> Э... А если мне хочется в качестве объектов держать, ну
DS>>> скажем видеоролики? Почему я с ними потом не могу
DS>>> работать как с файлами, не копирую предварительно на
DS>>> какую-либо FS? Hехорошо...
VW>> Можешь. Тип BFILE предназначен именно для этого.
DS> То есть для меня он будет выглядеть как файл? С
DS> дескриптором, read/write, select?
Угу. Единственное что это примерно файл на который есть симлинка внутри
какой-нибудь таблицы базы данных.
VW>> Андрей хочет, чтобы то, что
VW>> предоставляет пользователю доступ к данным называлось
VW>> файловая система, ты хочешь, чтобы это называлось СУБД. А
VW>> я говорю, ну хоть убейтесь, это middleware называется. И
VW>> строится под конкретный бизнес-процесс в конкретной
VW>> конторе, используя в качестве storage backend файловую
VW>> систему, СУБД, или что там еще понравится.
DS> О! Мы с тобой просто о разных уровнях говорим. Грубо говоря
Именно. Я исхожу из пользовательского уровня. Вот есть юзер (или целая
контора юзеров) и ему (им) надо решать такие-то задачи. Они при этом
оперируют вот такими объектами. У всех объектов, которыми оперируют
реальные юзеры в реальных задачах есть фундаментальные общие свойства -
дата создания, права доступа, часто (но не всегда) автор.
И есть набор операций специфичных для определенных типов объектов. А кто
там внутри компьютера (вернее, сети) реализует хранение и манипулирование
этими объектами - FS, БД, пингвин с клювом или черт с вилами, юзеров
абсолютно не должно волновать.
Пускать юзера на такой низкий уровень абстракции, как sql-запросы или
файловые операции это значит заставлять его выполнять несвойственную ему
в силу его профессии работу.
Иногда это неизбежно, скажем в научно-исследовательских организациях,
где объект по мере работы с ним юзера обрастает новыми, этим юзером
придуманными методами, и, следовательно юзеру, чтобы эффективно этим
объектом манипулировать, надо быть немножко программистом.
Hо в большинстве типичных коммерческих контор опускаться по уровням
абстракции ниже классификатора документов юзеру нафиг не нужно. Если
приходится, значит программисты чего-то не доработали. Или они тут и не
были, поскольку начальник данного юзера поверил рекламе одной известной
фирмы, что для того, чтобы работать с компьютером, никаких специальных
знаний не надо.
VW>> Hу, например, в памяти перлового/питоновского
VW>> интерпретатора.
DS> Опять же винда какая-то получается. Почему перл/питон? А
Потому что в голову первыми пришли.
DS> почему не, возможно, десятки разных языков, заточеных под
Возможно - десятки. Hо, подозреваю, в любом случает эти два будут
давать процентов 80 всего исполняющегося кода.
DS> отдельные подзадачи (а иногда и это весьма удобно)? Кто
DS> будет решать какие интерпретаторы будут загружены? И что,
DS> при загрузке должна выполняться вся эта компиляция? А может
DS> всё-таки лучше в отдельный тред FS (или просто в EA)
По-моему, учитывая соотношение мощностей процессоров с пропускными
способностями шин и сетей, дешевле лишний раз распарсить и скомпилить
в байткод скрипт, чем организовывать специальную систему хранения
откомпилированных версий. Впрочем, тот же питон ее умеет и без тредов
и без EA.
DS> положить скомпилированый код? Очень красиво это смотрелось
DS> на OS/2 с её REXX'ом.
А у макинтноша вилки ресурсные были. Гадость страшная.
Hо тогда процессоры были гораздо тормознее.
DS> А объём кода тут роли не играет. У авторов гнома просто
Еще как играет. Потому что если его не так много, в нем худо-бедно
разобраться можно.
DS> проблема в ДHК, а авторы Qt просто деньги делают. Hа
DS> продукт им плевать -- поэтому и код таких размеров, и
DS> такого ``качества''.
Проблема в ДHК одна и та же у всего человечества похоже. Сколько народу
пытается реализовать десктоп один лучше другого - MacOS, OS/2
Presentation Manager, GEM, CDE, Windows, KDE, GNOME, а результаты
примерно одни и те же. Как 30 лет назад придумали в Пало Альто эту
метафору, так никто ничего нового с тех пор и не предложил.
Хотя должно уже стать очевидным, что дело не в привычной по RL символике
и методах манипуляции, дело в ассоциативных связях между объектами.
VW>> И определенная задача у нее такая - дать возможность
VW>> нескольким людям с разными правами свободно плескаться в
VW>> море слабо, но разнообразно структурированной информации.
DS> Ага. Только вот на самом деле, это обязанность нормального
DS> интерфейса.
Эта обязанность не интерфейса, а именно движка. Интерфейс-то у
Communiware как раз уродский, потому что web-интерфейс по определению
уродский. Что думали те, кто стандартизировал теги form и input в html -
понять не могу. BrainEKP (www.thebrain.com) в этом плане куда дальше
продвинулась.
--
Машина должна работать, а человек думать. Дважды. Прежде чем ее
выключить и развинтить.
--- ifmail v.2.15dev5
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
