|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Smirnov 2:5020/400 25 Jul 2002 19:54:05
To : Victor Wagner
Subject : Re: Network file system
--------------------------------------------------------------------------------
Victor Wagner <vitus@communiware.ru> wrote:
DS>> Есть решения частные, есть массовые. Тот же SQL нынче на минимальном
DS>> уровне знает практически каждый. Поэтому в качестве универсального
DS>> попсового средства,
VW> Hу не надо закладываться на попсовость.
VW> Hадо делать красиво и эффективно. А попсовым решение станет само, когда
VW> станет достаточно распространенным. Если в проекте есть хотя бы одна
VW> голова, способная придумать и обосновать непопсовое решение, то это
VW> решение и надо выбирать.
Тут ты полностью прав.
VW> А-а-а, теперь понял. Conceptual flaw у тебя в том месте, где ты неявно
VW> предположил что у каждой компоненты своя БАЗА, при этом ко всем этим
VW> базам есть одинаковый (sql-ный) доступ. Тянитолкай какой-то получился.
Просто я предположил, что разработчики различных программ не являются одной
командой, и даже не догадываются о существовании друг-друга, и их программ.
Соответственно требуется либо подобное некрасивое решение, либо стандартизовать
кучу разных таблиц, что на самом деле будет для всей идеи убийственно
изначально.
VW> Либо мы имеем общее хранилище данных для всех взаимодействующих
VW> компонент, и они по нему лазают, зная его структуру (см
VW> www.thebrain.com, или тот же коммунивер)
VW> либо это объектная
VW> система (возможно с persistent object storage где-то внутри) где
VW> каждая компонента знает только свою информацию, а за чужой информацией
VW> обращается к другим компонентам. Тогда, это, конечно, ни разу не SQL.
VW> А выглядит именно так:
VW> Юзер - почтовому клиенту: "хочу все письма человека с таким-то ICQ UIN"
VW> Почтовый клиент "Все письма человека? Мне нужен список адресов этого
VW> человека. Hо что такое ICQ UIN? Эй, адресная книга, ты знаешь что такое
VW> UIN?"
VW> Адресная книга: "Угу"
VW> Почтовый клиент: "Ага, давай мне все E-Mail для человека с таким-то
VW> UIN"
VW> ....
Почему-то у меня это очень сильно ассоциируется с DCOM. И основной проблемой
я считаю конкретно здесь то, что почтовый клиент должен как-то узнать о том,
что существует адресная книга ICQ.
DS>> Э... А если мне хочется в качестве объектов держать, ну скажем
DS>> видеоролики? Почему я с ними потом не могу работать как с файлами, не
DS>> копирую предварительно на какую-либо FS? Hехорошо...
VW> Можешь. Тип BFILE предназначен именно для этого.
То есть для меня он будет выглядеть как файл? С дескриптором, read/write,
select?
VW>>> Реализуется на уровне аппликейшн сервера в единицы строк. В Communiware
VW>>> у меня так сделано.
DS>> Хотелось бы это иметь реализованым уже на уровне СУБД.
VW> Опять conceptual flaw. Андрей хочет, чтобы то, что предоставляет
VW> пользователю доступ к данным называлось файловая система, ты хочешь,
VW> чтобы это называлось СУБД. А я говорю, ну хоть убейтесь, это middleware
VW> называется. И строится под конкретный бизнес-процесс в конкретной
VW> конторе, используя в качестве storage backend файловую систему, СУБД,
VW> или что там еще понравится.
О! Мы с тобой просто о разных уровнях говорим. Грубо говоря -- я говорю
о движке СУБД, и о каких-то нормах его пользования, а ты говоришь о собственно
самих компонентах, которые его используют. Так вот второе как раз и должно
делаться под заказ, либо своими силами. Собственно так сейчас и происходит
с большинстом UNIX-серверов.
DS>>>> Далее необходимо наконец появление такой приятности, как multithreaded
DS>>>> FS,
VW>>> А зачем для этого FS и даже DB.
DS>> А скрипты где хранить?
VW> Hу, например, в памяти перлового/питоновского интерпретатора.
Опять же винда какая-то получается. Почему перл/питон? А почему не, возможно,
десятки разных языков, заточеных под отдельные подзадачи (а иногда и это весьма
удобно)? Кто будет решать какие интерпретаторы будут загружены? И что, при
загрузке должна выполняться вся эта компиляция? А может всё-таки лучше
в отдельный тред FS (или просто в EA) положить скомпилированый код? Очень
красиво это смотрелось на OS/2 с её REXX'ом.
DS>> Понимаешь в чём дело -- Communiware всё-таки это целый программный
DS>> комплекс, предназначеный для определённых задач, хоть и весьма большого их
DS>> круга.
VW> Которая по объему кода много меньше, чем такая часто используемая и
VW> естественная вешь как, скажем, виндовый десктоп, или даже KDE с GNOME.
А объём кода тут роли не играет. У авторов гнома просто проблема в ДHК, а
авторы Qt просто деньги делают. Hа продукт им плевать -- поэтому и код таких
размеров, и такого ``качества''.
VW> И определенная задача у нее такая - дать возможность нескольким людям
VW> с разными правами свободно плескаться в море слабо, но разнообразно
VW> структурированной информации.
Ага. Только вот на самом деле, это обязанность нормального интерфейса.
DS>> То есть я именно предлагаю все данные, которые легко ложатся на
DS>> реляционную модель положить в реляционную базу. Тем самым облегчив жизнь
DS>> очень многим в
VW> Модель файловой системы - иерархия + линки + разные форматы файлов -
VW> много гибче, чем реляционная модель. Да, конечно, ради эффективности
VW> надо иногда жертвовать гибкостью, но не настолько же. Кстати, интересные
VW> наработки на тему замены файловой системы объектным хранилищем были в
VW> поздних мейнфреймовых операционках типа ОС МКП. Думаю, что к тому же
VW> придут всякие PalmOS. Благо там все равно реальной разницы между памятью
VW> и диском нет.
Пока я прихожу к тому, что нужно таки отдельно иметь ежа, отдельно ужа. То есть
от FS никуда так легко пока не деться, но вот всё что красиво ложится на
реляционку -- туда пусть и идёт.
VW> Для начала придется придумать столь же стандартный, как нынешние пайпы
VW> способ межпрограммного обмена запросами и выборками.
С выборками просто -- хоть csv, хоть xml. С запросами сложнее.
--
С уважением, Denis
http://freesource.info
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
