Ответ на »сообщение 2419« (Ка джа)
___________________________

Кажется еще немного и в документы начнут включать не просто структуру, но и механизм, ибо в ФС не хватает подходящего механизма.

Активные документы системы Oberon (Oberon System) включают не только структуру, но и механизм. Само слово "аплет" придумал Микаэль Франц. Ученик Вирта. Как он говорил, третий пользователь Oberon System (после Вирта и Гуткнехта).

В системе Oberon почти всё есть документ (подобно тому, как в системе Plan 9, созданной при активном участии авторов UNIX, файл стал практически всем).

В Sun, изучив в 1992-1994 гг. Oberon System, идею сильно извратили. Потому и аплеты мы во многом воспринимаем негативно и как атрибут исключительно веб-страниц. Только потом люди стали задумываться о том, что веб-документ и обычный документ не должны различаться. Что сам документ может быть вообще приложением. Что браузер -- это не только средство навигации по веб-страницам, а универсальный инструмент навигации по любым документам.

Но в системе Oberon это было изначально. В начале 1990-х годов. И это не скрывалось. Были книги. Была бесплатная система со всеми исходниками. И сделана была под DOS, Windows, MacOS и почти все Unix'ы. Был авторитет Вирта и ETH.

Но индустрия, прекрасно это зная, повела людей другим путем. Так, как было выгодно именно ей.

Ответ на »сообщение 2413« (Руслан Богатырев)
___________________________
Усложнять — просто, упрощать — сложно (c)

Росе нужно иметь дивиз. Предлагаю следующий "Гвозди против шурупов"

Ответ на »сообщение 2418«

Значит для Вас мейнстрим стал уже логичным? И "факторы" эти тоже? И сколько лет для этого понадобилось?

В компании где я работаю так и не услышал причины, по которым новый проект пишется на C++/Java, почему именно такое разделение по группам и языкам? почему именно эти языки? Где документ, в котором бы аргументировалось именно такое решение с обсуждением достоинств и недостатков других альтернатив.

Проект пишется с нуля, в нем участвуют десятки человек по всему миру. Так что свобода выбирать и разделять была.

Самый логичный "фактор", который мне привели, это то что некоторые менеджеры "знакомы" с C++, а некоторые с Java. Вот и поделили как знали. Просто боялись за своё ЕГО - как то нужно было бы работать с подчинёнными, которые чисто формально больше знают. А учить что то новое не хотели. Вот и весь логичный "фактор".

Другой пример Linux. Причина по которой выбрали его это: клиенты не хотят Windows, и есть корпоративная Linux, вот и все. А простой вопрос нафига ставить ОС общего назначения на applience, к которому ни у кого не будет доступа на прямую, я так и не получил ответа. Надеюсь что у клиента будет стоять другой корпоративный MiniLinux, но это тоже абсурд. И при всем при этом, эта супер надёжная система пару дней назад просто зависла на операции с Source Control. Поспрашивал народ, говорят что вообще для Linux это хоть и редкость, но постоянство. Т.е. все таки виснет она иногда. Причём разные версии, и не только эта корпоративная.

Вот вам и логика в принятии решений, влияющих на несколько лет в перед. Может и есть документы почему да как, но наверняка там будет что то типа "ну... C++ и Java и Linux - это ведь хорошо! ну вот и выбрали... вот и мучаемся... Вот..."

Возможен ли вообще здоровый минимализм в отношении ФС? Ведь "сарай" получается немалый - структурированные документы в структурированной файловой системе... Одни механизмы... другие над первыми... или вместо первых... Кажется еще немного и в документы начнут включать не просто структуру, но и механизм, ибо в ФС не хватает подходящего механизма.

Ответ на »сообщение 2402« (Руслан Богатырев)
___________________________

Паранойя сложности -- это наркотик. Который точно нащупала ИТ-индустрия и ловко этим пользуется. Ей это позволяет не останавливать производство все новых и новых пилюль для массового потребления (что пользователей, что разработчиков, что проектировщиков), постоянно извлекать прибыль, ставить в зависимость от себя. И всем хорошо.

Знакомая песня. Когда-то, много лет назад, когда я еще варился в тепличной академической среде, я тоже любил порассуждать о мейнстриме, который, вот ведь незадача, устроен совершенно неверно в целом и не хочет программировать "правильными" научными методами в частности. А когда пришлось, по стечению обстоятельств, в этот мейнстрим самому нырнуть, то спустя некоторое количество лет вдруг оказалось, что изнутри видны некоторые факторы, которые ну никак не разглядеть "с орбиты" (как выражаются по адресу One Microsoft Way, Redmond, WA). И если учесть эти факторы, то окажется, что те самые "правильные" методы и языки --- отнюдь не желаемая "серебряная пуля".

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

Раз уж мы начали навешивать друг другу ярлыки с привлечением  психиатрии, предложу встречный вариант: "Аутизм простоты" (http://ru.wikipedia.org/wiki/%D0%90%D1%83%D1%82%D0%B8%D0%B7%D0%BC).

Ответ на »сообщение 2414« (Димыч)
___________________________

Как формализовать доступ к файлам (документам) со столь разнородной структурой, как например, *.jpg, *.dwg, *.txt, *.doc? На уровне страниц файла?


А в чем проблема? В БД могут быть такие поля, куда записываются данные в произвольном формате. Сам документ может иметь сложную структуру, включая рисунки, таблицы, музыкальные файлы и т.д. Любой рисунок или импортированный из другой ОС файл экзотического формата можно "обернуть" в такой документ. Более того, можно даже иметь в файловой системе - БД все документы единого, но сложного составного формата. В самом документе могут храниться и указания на типы приложений, которые по умолчанию могут работать с таким документом или его частями. Конечно, документ сложного формата будет дольше обрабатываться, но описанный механизм и не предполагается применять к исполнимым файлам, для которых скорость приоритетна. Сам документ не имеет смысла размазывать по нескольким полям БД (страницам файла).

Всё, что сложно реализовать в централизованных таблицах метаданных, проще реализовать в виде тегов, содержащихся в самом документе. Мне кажется, что проблема WinFS в излишней централизации сложноформализуемой информации о структуре, формате и содержании документов. Централизовывать целесообразно лишь то, что универсально для любых документов.



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



Ассоциативный поиск и не должен быть очень "умным" или претендовать на полноту. Но он должен быть удобным. Это лишь способ ускорить поиск, основываясь на сохраненных данных о связях между документами, копировании информации из одного документа в другой, о совместной работе с несколькими документами, о пользователях, работавших с теми или иными документами и т.п. См. сообщение »сообщение 2219« , пункт 7.

Ответ на »сообщение 2413« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2411« (Сергей Прохоренко)
___________________________

Добавлю также полезные вещи, отсутствующие в хранилищах данных:
1. Возможность рецензировать/аннотировать документы, устанавливать рейтинги.
2. Сопровождение документов метаданными об источнике и приложении, генерировавшем эти данные.
3. Делегирование прав доступа к документам.

Не слишком ли многих людей Вы хотите оставить без работы? :)


Согласно закону Паркинсона объем работы увеличится в другой области.

Ответ на »сообщение 2414« (Димыч)
___________________________

Можно ли подобное сделать для файловой системы?
WinFS ?

При обсуждении служебной СУБД хочу упомянуть одну потенциальную проблему, которая неявно присутствует.

БД работает с такими категориями, как запись (кортеж), домен, отношение (таблица) и далее по нарастающей (см. работы Кодда). И хотя в большинстве случаев пользования/администрирования БД это можно не знать, при проектировании все же приходится учитывать.

БД формализуется от самого мелкого элемента до самого крупного; возможно построить матаппарат ко всем процессам, происходящим в базе и вокруг нее. Можно прописать механизмы конкурентного доступа (версионный/блокирующий/комбинированный). Поэтому возможно оперирование сущностями БД в контексте datawarehouses и понятие нормализации.

Можно ли подобное сделать для файловой системы? Не знаю.
Как формализовать доступ к файлам (документам) со столь разнородной структурой, как например, *.jpg, *.dwg, *.txt, *.doc? На уровне страниц файла?

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

Возвращаясь к началу сообщения, проблема состоит в том, что доступ к файлам и файловой системе плохо формализуется (по сравнению с БД) и могут возникнуть проблемы, если скрещивать файловую систему и БД "в лоб".

Ответ на »сообщение 2411« (Сергей Прохоренко)
___________________________

Добавлю также полезные вещи, отсутствующие в хранилищах данных:
1. Возможность рецензировать/аннотировать документы, устанавливать рейтинги.
2. Сопровождение документов метаданными об источнике и приложении, генерировавшем эти данные.
3. Делегирование прав доступа к документам.

Не слишком ли многих людей Вы хотите оставить без работы? :)