ну наконец-то, давно пора какой-нить dbfs появится, надеюсь это первый шаг.. может наступят времена когда mp3 tag и аудиопоток будут хранится как поля в записи

Ура спижживанию WinFS из Longhorn!

> Ура спижживанию WinFS из Longhorn!

... которое тоже не является гением мысли Microsoft а "позаимствовано" из IBM AS/400.

кто у кого с3.1415...здил

2 anonymous (*) (2003-09-07 05:13:52.878591):

> Ура спижживанию WinFS из Longhorn!

Ура с....иванию translators из Hurd!

а можно обьяснить простому смертному что это такое и чем это для него будет хорошо?

Я не пойму - ведь вроде рейзер тоже стремится к тому же самому ? Зачем изобретать еще один велосипде когда можно довести до ума существуюший ?

имхо, это они и собираются сделать. поля известных форматов файлов станут расширенными атрибутами. описания же павил преобразований для работы с различными форматами файлов будут записыватся в нотации xml.

Идея хранить файлы в базе данных далеко не нова. МS заявила о разрабатываемой возможности. Разработчики Linux-решений тоже заявили.

Поглядим у кого получится лучше.

Говорить что кто-то у кого-то спер идею глупо. Многие разработки идут параллельно. Выживает сильнейший. Действительно, пока Linux-разработки похожи на догонялки с Windows. Но наверняка наступит момент, когда Windows будет догонять Linux.

Собственно уже догоняет. Не зря ж они специальную группу по наблюдению за Linux сделали. :)

2 anonymous (*) (2003-09-07 05:13:52.878591)
Что касается WinFS в Longhorn, то, если я не ошибаюсь, на какой-то последних своих конференции Microsoft приоткрыла, что такое WinFS.
И оказалось, что это всего-навсего обыкновенная NTFS с прикрученной по умолчанию службой индексирования.
Что несколько отличается от того, что делает Рейзер и что есть в AS400 (или как там оно теперь называется ;)
Точных ссылок не помню, читал в журнале.

Так объясните все-таки глупенькому - это те же самые идеи что и в рейзере (заявленные, но еще не реализованные ?)

> Ура спижживанию WinFS из Longhorn!

Блин, точно не помню, но такие идеи явно не связаны с мелкомягкими - существует масса наработок с подобным механизмом, и к мелкомягким они отношения никакого не имеют...:)

Какая разница у кого, главное что спижжено. А реализация затянется на годы - как все гпльное.

Имхо, оно будет потормознее и места больше файлики будут жрать(по крайней мере в первых релизах).

проблема в том, что кроме тормозов ничего нового к традиционным файловым системам с поддержкой атрибутов и разделяемых по NFS/SMB (и уж тем более комплексным SAN решениям) эта идея не принесет.

поэтому будущим тут и не пахнет. очередная идея из области "трехмерного пользовательского интерфейса" ...

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

С другой стороны - это направление ориентируется на десктопное применение, не серверное.

Хм. А вот интереснее было бы сделать ФС как реализацию стандартов OMG. таких как MOF и CWM. Вот это реально интересно было бы, да и на голову выше того что они собираются сделать. Темболее что модели MOF можно хранить где угодно, хош XML/XMI хош БД. Это становится уже не важно :)

Korwin: Без сомнения. Но никаких свежих идей я не вычитал (может плохо читал). Нити в файлах были еще в HFS (в частности там иконки хранились), в Win они есть и на NTFS, причем есть несколько недоработанный (но все же) механизм их индексирования. В Linux есть XFS, где EA уже почти можно использовать.

2Murr
полностью согласен
IMHO делается это все побольшей части для маркетинга и на руку производителям hardware.

TO Dead

Ты свам то понял что глупость сказал ? :)

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

Dead: угу... :) пока софт пишут производители hardware без работы не останутся :))

А на Slacware оно будет работать? )))) По-моему это не так удобно как кажется разработчикам этой ботвы.

Я читал про похожую разработку для KDE. Она еще в зачаточной форме. Суть не сколько в форме хранения данных, а в способе их поиска и сохранения. Предлагается пересмотреть фундаментальный принцип почти всех современных файловых систем - иерархической организации, и перейти к более интуитивной и понятной человеку. Грубо говоря, когда мы ищем наш договор на поставку болтов М6, мы не лезим в каталог C:\My Documents\dogovora\bolti\m6\ где, как мы ожидаем, должен лежать файл с договором dogBoltM6-23.txt, а вводим критерии поиска (типа: договор, болты, Иван Иванович, до 1 числа прошлого месяца) и получаем подпадающие под эти критерии информацию. Таким образом даже неряшливый лобзик, который не обременяется раскладыванием своих файлов по подкаталогам сможет легко отыскивать информацию.

аи

Да, идея не понятна. Кажется где-то проскакивала статейка, про то, что на современных винтах столько данных хранится, что пользователям пора обзаводиться локальными поисковиками... ;-)

Это называется "N-мерное хранилище данных". Не сказал бы, что она во всех случаях более интуитивна и понятна для человека и, конечно, не является панацеей. В некоторых случаях может только увеличить неразбериху. А вообще, красиво:

/home/user/documents/[type=report,date='01-09-2003']/

ваще пора делать фс примерно как в пальме. файлы - это пережиток *никс и вин*

я правда еще не придумал как именно, но делать надо

три года назад читал статью как мужику удалось прикрутить MySQL как том файловой системы к Линуксу. мона было по таблицам ходить как по каталогам, а по записям как по файлам. при этом одновременно можно было к той же базе данных (отраженной в FS) обращатсья как к обычной БД. задумка была даже реализована, только че-то там напильником надо было доделывать.

Я сейчас тоже сильно задумался над такой системой. Посмотрел уже закрытый Ефрат. Там как хранилище так и ворфлоу. Я пока решил реализовать это только в виде хранилища (воркфлоу потом вполне можно доднлать, но он зависит от конкретной организации). Смысл таков: Есть сервер он по XML-RPC получает запросы get, put, search. Вот и все. а в том-же ворде и ОО вместо кнопки сохранить выводим кнопку которая запускает макрос, который сохраняет все в temp и спрашивает пользователя о полях которые обязательно нужно вбить. Потом документ с полями улетает на сервер. FS тут нет....

Может кто заинтересован, может можем вместе работать, а то одному сложновато такое тянуть.

> /home/user/documents/[type=report,date='01-09-2003']/

в таком виде, как ты написал, это уже было. в OpenVMS.

А может оставить файловой системе её назначение - хранить файлы, в конечном-то счёте! Т.е. быть просто надёжной файловой системой с быстрым доступом.
А для всякой хрени про болты можно пользоваться сервером документов, например SharePoint от MS.
Малоубедительно выглядят полезности такого решения, кроме того что это просто модно.

ps Storage is part of a larger design for a new desktop environment...
... replace the traditional filesystem with a new document store.

Ключевые слова. Очень смахивает на SharePoint :-) Здорово, но причём тут замена традиционной ФС вообще на ФС-БД?

А кто чтонибудь свободное типа шарепоинта знает?

dem: по XML-RPC получает запросы get, put, search
Есть более простой вариант. get и put уже довольно хорошо обслуживаются разными файловыми системыми(сетевыми или нет). А search - это работа для простой (find|locate)-подобной программы с поддержкой аттрибутов, анализа содержимого нескольких типов файлов и кеширования результатов.
В таком случае нужно только добавить к клиетнскому UI диалог "найти по чему-то-там".

И вообще, все эти "хранилища" сильно похожи на:
#!/bin/bash
select file in $(find ... | xargs grep ...) ...

IMHO.

Согласен с PitStop. Зачем все это нужно? Боюсь, все это будет походить на какую-то advanced помойку.

2DonkeyHot Ну насчет get put я согласен. Просто можно давать ссылку на то где хранится документ реально в атрибуте скажем URL. А вот насчет скрипта не согласен. Это не масштабируется. Причем тут еще есть фишка. У каждой организации несколько иные требуются аттрибуты. Опять-же неплохо-бы хранить версии документов. Тоесть я как админ должен уметь задать как минимум 1) Схему атрибутов для того или иного МИМЕ типа, указать их обязательность тип и перечень возможных значений (DTD напоминает?). 2) ACL и аудит. Кстати на эту тему очень заинтересовался FramerD т.к. реляционные БД не обеспечивают необходимой гибкости с сохранением скорости. Никто не подскажет ресурсов с кикстартом по этой нереляционной БД. А то у меня она лезет на их сервер хоть ты тресни...

2anonymous (*) (2003-09-08 11:43:49.515863) С пальмой помойки не получается почемуто? А там похожая система и объем занимает меньший...

2 dem (*) (2003-09-08 11:54:32.657259)
> ... и объем занимает меньший...

Ключевые слова!

с пальмой не получается помойки потому как там для помойки хрен развернешься, даже 256 мб маловато для нормальной помойки

но в то же время пальма - это шаг вперед в сравнении с мультитредовыми-журналируемыми-индексированными-продвинутыми нтфс и других рейзеров

проититит

>А вот насчет скрипта не согласен. Это не масштабируется.
А почему, собственно? Я этой проблемы пока не вижу.

>ACL и аудит ...
Первое во многих ФС есть, второе - просто реализуется.

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

>У каждой организации иные требуются аттрибуты...
>Схему атрибутов для того или иного МИМЕ типа,

Тут нужно различать 2 уровня решений.
1. Каждый(или абсолютное большинство) документов, используемого в организации, имеют различимый программой тип. Этого на обычных оффисных програмках(типа MSWord, excel, etc.) не получить - для этого нужен редактор, _навязывающий_ структуру документа. В таком случае все _важные_ аттрибуты у документа внутри - и тогда да - документы должны лежать в БД со своими сложными алгоритмами поиска и пр...

2. При обычном же подходе с неструктурироваными документами множество _осмысленных_ аттрибутов и практически не отличается для разных типов документов (ввиду неразличимости оных) и содержит, может быть, до 10 аттрибутов. В этом случае всякие FramerD - пушкой по воробьям.

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

http://otn.oracle.com/products/ifs/ Раньше называлось InternetFS

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

Ребят сил моих нету, вы наверное под PalmOS не писали ничего.
Структура хранения записей в PalmOS никакой не шаг
и не вперед просто просто бл**ь, еб***е архитекоры
PalmOS почемуто бл**ь решили что большинство
программ для Palm будут работать с микроскопическими записями
и решили "помочь" программистам - сделали убогие
БД и не сделали файлы вообще.
PalmOS не поддерживает ни полей записей ни поиска в БД, запись
максимум 64k и это просто набор байт без типа.
Особенно удобно этим еб***тым "шагом вперед" пользоваться если нужно
сохранить картинку или текст размером > 64k.

За исключением вышесказанного базы данных в PalmOS
это конечно прорыв по сравнению
"мультитредовыми-журналируемыми-индексированными-продвинутыми
нтфс и другими рейзерами"

>еб***е архитекоры PalmOS почемуто бл**ь решили что большинство программ для Palm будут

аха, был еще както один перец, который заявлял "640кб хватит всем и каждому, и пусть никто не уйдет!"

>За исключением вышесказанного базы данных в PalmOS

дык никто и не говорит: "пальму в лонгхорн!" хотя и пень4 все еще поддерживает x86 real mode сегментную адресацию :)

2Troll Не матюгайся писали. В принципе 1) Такая организация удобнее для энд-юзера 2) Удобнее для меня т.к. я еще ни казу не слыщал чтобы в моих программах на пальме - "документ пропал". Ограничение 64 kb там не само-собой появилось - проц такой... Вобщем к идее это никаким боком не относится...

2DonkeyHot Вобщем вы меня пока не убедили. Скрипт не масштабируется потому-что он будет бегать по всей FS в поисках. А тот-же FramerD использует хэши. И я легко могу выдернуть все фреймы ссылающиеся на жданный или меющие в слоте нужный мне параметр. Атрибутов далеко не 10 их от 1-URL до бесконечности и не обязательно все вводятся в данном случае реляционные БД не катят (можно сэмулировать с помощью 3-х таблиц но это гемморой).

Вобщем как я вижу мало кто сталкивался с ордами недоюзеров которым больше SonyPS давать нельзя Ж-) это радует, но огорчает что я сталкивался...

2 dem (*) (2003-09-08 15:08:22.647596)
> Вобщем как я вижу мало кто сталкивался с ордами недоюзеров которым больше SonyPS давать нельзя Ж-) это радует, но огорчает что я сталкивался...

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

2dem
>1) Такая организация удобнее для энд-юзера
Такая организация не имеет никакого отношения к энд-юзеру
он про нее не знает. Все что он видит это список имен
документов, картинок, книг, e-mail-ов etc а уж в чем они там
хранятся дело OS и программистов, а вот как раз программистам
очень не удобно этой самой БД пользоваться.

>2) Удобнее для меня т.к. я еще ни казу не слыщал чтобы в моих
>программах на пальме - "документ пропал".
Если каждый день бекап по HotSync делать как это
обычно бывает с пользователями Palm то действительно
сложно что-то потерять независимо от того как
именно хранятся данные =)

>Ограничение 64 kb там не
>само-собой появилось - проц такой...
Гхм может быть я тебя удивлю но я таки нписал
FS поверх палмовской БД с поддержкой файлов
_любой_ длины и даже ни разу не вспоминал пока писал
какя у процессора разрядность.
Может дело все таки не в прцессоре?

>Вобщем к идее это никаким боком не относится...
Я и говорю что палмовские БД ни к каким идеям
никаким боком не относятся.

Sorry не подписался

>Скрипт не масштабируется потому-что он будет бегать по всей FS

Если ему не приделать кеш ответов(бд. с аттрибутами):-) Не понимайте меня буквально - я не считаю, что это нужно делать это на sh+find+grep (хотя это возможно). Я пытаюсь сказать, что данная задача решается более просто(по сравнению с реализацией всего с нуля) - используя готовые примитивы доступа к файлам и небольшую базу данных с содержимым типа (аттрибут,значение,файл) и переделывая 2-3 диалога+функции в "основных" офисных программах.

Если только у Вас нет больших обьемах хорошо структурированых данных :-(что есть довольно редкая ситуация)-:. В этом случае Вам действительно нужно более качественное решение(тот же FramerD) - но Вас тогда не должно сильно беспокоить интеграция с office-ами - по причине плохой(пока) структурированости данных, ими поставляемых.

>И я легко могу выдернуть ... . Атрибутов далеко не 10
Это вторая причина моих возражений. Вы то можете. Но трудно представить, чтобы большАя часть пользователей (а тем более "недоюзеров") смогла бы правильно формулировать запросы к этой самой FramerD пользуясь большим числом параметров. Сложность в том, чтобы заставить их помнить, что какой параметр обозначает, и уметь излагать свои желания на понятном системе языке.

2Shaman007 (*) (2003-09-07 21:15:18.183109)

К проекту "Соломон" имеешь кокое-либо отношение?

:-)

2dem (*) (2003-09-08 11:54:32.657259):

> 2anonymous (*) (2003-09-08 11:43:49.515863) С пальмой помойки не
> получается почемуто? А там похожая система и объем занимает меньший...

В палме - помойка натуральная :) Просто её не видно до поры до времени.

Там доступа прямого к данным нет, а только через морду программы. А что там программа насоздаёт - никому не ведомо.
Простой пример. То, что память палма тормозит нещадно - факт общеизвестный. То есть ежели надо к базе нормальные индексы прикрутить - будь добр ручками. Я вот валяются эти индексы в отдельной базе, и что это такое никому и ничему кроме этой программы неведомо.
Добавить осталось лишь то, что сносить данные программ при деинсталляции оных палмось очень не любит. Не помойка, нет?

А поиск там вообще зело весело - ось обращается к каждой программе по очереди - "А нет ли у тебя, милайа, записей с такой-то строчкой унутре?" :-)

Знаешь, если в тех же виндах дальше эксплорера и "My Documents" не лазить - но на первый взгляд тоже помойки нет. Хотя мы же знаем что там на самом деле ;)

Всё это (палмы и прочая ботва) не имеет никакого отношения к теме.

ИМХО система "Storage", как и все аналогичные, будет полезна до первого неизвестного системе формата файла.

Re:

2Dimentiy Вот потому и обращается что так не будет неизвестных ей форматов. Вобщем я думаю я понял на чем основано ваше скептическое отношение.

А вот что конструктивного вы можете сказать? Может есть какие идеи по уменьшению вселенского хаоса каким стали многие FS на HDD?