Семантический десктоп. ОС без файлов и документов (продолжение)

побыстрей бы выпустили WinFS, в FS я еще не видел SQL-инъекций :)

Основная проблема, возникающая при практической реализации подобных идей — это как перенести сохранённую вне файлов информацию на другую систему.

Вообще в Windows 7 вроде некоторые из отдельных идей WinFS внедрены, прежде всего так называемые Libraries и т. н. Federated search.

"Как считаете, будет ли этот подход иметь место в будущем, или от файлов и документов никуда не уйти? Просто я делают сейчас один проект, в котором бы хотел использовать подобные идеи, хотелось бы оценить их перспективы."
1) Считаю что будет, но большой популярности не получит (Я рассматриваю промежуток в 5 лет).
2) Используй идеи в проекте!
3) Есть перспективы произвести впечатление на владельцев яблофонов.

А по теме... winfs это уровень абстракции данных! Это все равно как для работы в инете tcp пакеты вручную собирать, или положиться на ОС. может ты бы это сделал иной раз и быстрее и эффективнее, но взял и переложил это на железные мозги ;-) Что ты в winfs хранишь? Что ты с этим делаешь? Есть ответ?

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

Файлы и документы не нужны. Нужно только порно!

Файловая система такого рода возможно появится. Когда придёт ПО которое скажет "мне это надо", и которое будет стоить того.

А может быть и не появится. А ПО будет работать с данными, лежащими на традиционной ФС, храня структуру и метаинформацию у себя.

Возможно второй вариант ближе к действительности, потому-что такое волшебное ПО особенного рода наверно не будет само являться ОС и будет нужнаться в прослойке системного ПО между собой и железом. А переписывать ОС наверно нет резона когда готовая есть.

который раз подтверждает что в мелкософте сидят далеко не идиоты

По ссылке - презентация написаного на Qt совта под офтопиком. Но никогда бы не догадался, что речь идет о ФС.

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

> Так то лишь гуйня-файлы-то и документы остаются

А не важно, как оно там на самом деле устроено, важно то, что пользователь никаких файлов не видит.

> В принципе еще в ROXе подобный обьектный подход пытались использовать

ROX is a fast, user friendly desktop which makes extensive use of drag-and-drop. The interface revolves around the file manager, or filer, following the traditional Unix view that `everything is a file' rather than trying to hide the filesystem beneath start menus, wizards, or druids. The aim is to make a system that is well designed and clearly presented. The ROX style favours using several small programs together instead of creating all-in-one mega-applications.

Спасибо, почитаю.

> А у меня ссылко без звука-что за кодек надо?

У меня mplayer выдает такое:

Opening audio decoder: [dmo] Win32/DMO decoders
GetOutput r=0x0 size:24576 align:1
StreamCount r=0x0 1 1
AUDIO: 44100 Hz, 2 ch, s16le, 331.6 kbit/23.50% (ratio: 41455->176400)
Selected audio codec: [wma9dmo] afm: dmo (Windows Media Audio 9 DMO)

Оригиальная WinFS (Windows Future Storage) представляет собой именно некотое абстрактное хранилице, которое работает поверх обычной NTFS. Только в самой NTFS лежат сами сайты, а в WinFS вся метаинформация и связи между файлами (информацией)

> А может быть и не появится. А ПО будет работать с данными, лежащими на традиционной ФС, храня структуру и метаинформацию у себя.

А потом появится еще одно ПО, которое придет еще с одним велосипедом. И еще одним. И будет зоопарк с костылями, вроде теперешних "раскрась qt-приложение в стиле GTK"

> А переписывать ОС наверно нет резона когда готовая есть.

Если ОС - это уровень работы с железом, то действительно нет резона. А если это уровень работы с данными, то почему и не сделать?

Файл это заголовок потока данных. Как только ты сможешь ответить внятно на два вопроса: как без файлов отделить твоё любимое порно от образа ядра и нахрена оно наддо - появится технология которая решит твою проблему.

> Если следовать этим идеям, то больше не будет файлов, больше не нужны пути к файлам и директориям.

Открой для себя волшебный мир игровых приставок. Файлы и даже целые файловые системы там есть, но пользователь их не видит.

> Если следовать этим идеям, то больше не будет файлов, больше не нужны пути к файлам и директориям.

Это самоцель? Какие проблемы будут решатся при таком подходе, и как пользователь будет эту абстракцию воспринимать?

С файлами и папками всё понятно - в обычной жизни с этим постоянно сталкиваешся - письма, счета, книги - всё это хранится как конкретные (физические) объекты. При этом файлы и папки на винте - как конечная смесь битов, которая без FS не имеет смысла. Зачем опять всё смешивать в кучу?

"...which unifies all forms of data and provides a consistent single interface."

Красиво выглядит написанным. Интересно только, как они себе это всё представляют...

> Если следовать этим идеям, то больше не будет файлов, больше не нужны пути к файлам и директориям. Как проблема - неготовность ПО для этого. Есть отдельные проекты вроде Nepomuk или noofs (который скорее был), но в целом пока все еще очень сыро.

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

#define fopen assert(0);

ё#define opendir assert(0);

и вот файлов и директорий нету. Дальше что?

> Как считаете, будет ли этот подход иметь место в будущем, или от файлов и документов никуда не уйти? Просто я делают сейчас один проект, в котором бы хотел использовать подобные идеи, хотелось бы оценить их перспективы.

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

> Красиво выглядит написанным. Интересно только, как они себе это всё представляют...

Посмотри ролик из инит-поста.

А ты сам его точно видел? Ты точно понимаешь то что там показано, и что такое файловая система?

То что в ролике показано, уже есть, и без участия M$ - называется это - MacOSX с сопутствующими приложениями. На винде я видел подобное как раз в этом ролике, на создание которого ессно было потрачена масса средств.

WinFS, или любая другая FS, вообще не имеет никакого отношения к этому видео бреду маркетологов, которые просто не понимают, о чем говорят.

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

BTW, M$ уже не раз продает всякое д@рьмецо под громкой вывеской - вроде как часы и солитер в первом виндовс, всего лишь за $99.9 (или сколько там стоило это чудо); информация на кончиках ваших пальцев, чтобы это не означало; .NET, который решает все ваши проблемы которые вы не могли решить раньше - и вот теперь этот скелет, который как я оченб рад, Баллмер не забывает доставать из шкафа и потрясая всем угрожать наступлением мира во всём мире.

Кстати, не забудь ещё M$ службы - их макретплэйсы, live.com, и прочие сервисы вроде службы траффика etc.

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

> То что в ролике показано, уже есть, и без участия M$ - называется это - MacOSX с сопутствующими приложениями. На винде я видел подобное как раз в этом ролике, на создание которого ессно было потрачена масса средств.

Это всё про эти самые "быстрые" поиски по содержимому документов, тегам mp3 и т.п.? Я не знаю, честно, на кого это рассчитано, в текущих реализациях. На "блондинку" с тремя mp3 и пачкой фоток, разве что.

Немного в сторону от темы... Бред maybe, но хочется просто мгновенный поиск по имени файла из любой программы, которая вообще в принципе может этим заниматься. locate это всё не то. Хочется чтобы все программы своими findfirst/findnext шуршали исключительно и только в ОЗУ (ну и чтобы дерево каталогов там уже заранее было всегда), а с реальными каталогами на диске взаимодествовал бы только некий драйвер.

> Это всё про эти самые "быстрые" поиски по содержимому документов, тегам mp3 и т.п.?

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

И эти применения (за исключением поиска) никак не относятся к WinFS.

Затем - примеры с вебом у них явно нацелены на использование сервисов от M$ - с "посторонними" сайтами они явно работать не будут.

Остальные "imagine" - извините, так это уже всё есть - в конкретных приложениях, и без всяких WinFS. Странно, что никто не дождался WinFS.

...а с реальными каталогами на диске взаимодествовал бы только некий драйвер.

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

> Искалка на маке, как я понял, делает себе индексацию файлов на FS (в том числе и на подключаемых приводах), а затем поиск осуществляется почти на лету - искалка всё время в системе, и взаимодействует с FS, отслеживая изменения... Гугловская наверное работает подобным образом.

Нет-нет-нет, это всё не то... Никаких специальных "искалок".

Хочется чтобы ткрыл какой-нибудь mc, в нужном каталоге жмакнул esc-?, вбил имя файла и МГНОВЕННО получил полный ответ на этот запрос.

> Хочется чтобы ткрыл какой-нибудь mc, в нужном каталоге жмакнул esc-?, вбил имя файла и МГНОВЕННО получил полный ответ на этот запрос.

итого, все что надо - чтоб locate умело на лету отслеживать изменения фс и держало в памяти демона с индексом? Курсовая для студента...

зы. искалка на маке по субъективным ощущениям здорово замедляет всякие компиляции и другие массовые операции с созданием/удалениеим большого числа файлов..

>Хочется чтобы ткрыл какой-нибудь mc, в нужном каталоге жмакнул esc-?, вбил имя файла и МГНОВЕННО получил полный ответ на этот запрос.

А потом оно чудесным образом должно синхронизироваться с устройством хранения данных и тоже мгновенно.

> А потом оно чудесным образом должно синхронизироваться с устройством хранения данных и тоже мгновенно.

С диска в память да, обратно - как у системы свободная минутка появится. Собственно кэширование информации на харде где-то так и работает, не? ;)

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

> итого, все что надо - чтоб locate умело на лету отслеживать изменения фс и держало в памяти демона с индексом?

Нет. Если уж переводить на locate, то чтобы сами системные вызовы обхода каталогов обращались к locate, а не к диску.

> Курсовая для студента...

Не программер ;)

>или от файлов и документов никуда не уйти?
А зачем от них уходить?

> А зачем от них уходить?

Просто как некий концепт, что можно ещё и "вот так".

> как некий концепт, что можно ещё и "вот так"

При отсутствии практического приложения даже наигениальнейшая идея претерпевает вырождение смысла. Т.е. делать „щоб було” нет смысла, если оно не востребовано реально.

Соответственно, всё выливается в вопрос: а нужен ли пользователю дополнительный уровень абстракции?

Я не против написать "Pink" и "Hey" чтоб оно мне нашло трек Pink Floyd - Hey You. Это может аудиопроигрыватель. Зачем мне ещё откуда-то это искать? Из файлманагера - чтоб скинуть на флеху. Вот... Для этого неплохо бы сваять отдельный модуль поиска, столь-же "обычный", как и диалог открытия файлов - для унификации этого поиска.

Картинки - а как? Рисовать её чтоль? Тут, думаю, поможет представление всей коллекции картинок пользователя с ручным выбором.

Документы - тут уже можно попытаться организовать поиск по содержимому, но эта штука будет жрать немало ресурсов... За ссылки на модели поиска по тысяче plain-text документов, к примеру, буду благодарен.

Осталось создать директории ~/{Audio,Foto,Video,Doc} и абсолютно все пользовательские документы кидать туда для удобства. А может и нет.

//Придумать как защитить это от первого попавшегося rn -rfv ~/* :)

>> А может быть и не появится. А ПО будет работать с данными, лежащими на традиционной ФС, храня структуру и метаинформацию у себя.

> А потом появится еще одно ПО, которое придет еще с одним велосипедом. И еще одним. И будет зоопарк с костылями,

Волшебное ПО новое не появится.

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

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

Все костыльно очень и без понимания нужд конечного пользователя. Эндузер хочет, чтобы как IRL, когда покажешь таксисту бумажку с надписью "улеца Ленена д.35", и он довезет до нужного места. Потому он же хочет, чтобы мейл отправленный для annaivanova1935@yandex.ru дошел до ivanovaanna1936@mail.ru. Потому что а какая нафик разница, ну ошиблись чуть-чуть, мне тете письмо написать надо, ну а вы что тут мне сделали? Потому ему не нужны теги и абстракции, он сейчас хочет найти веселую песенку, которая играла на прошлой вечеринке, а как называется, он не помнит, и тегов не помнит, ну вот ту, где ты-ды-дым ты-ды-дым вначале, а потом девушка поет.

А тут только libastral.

> Файл это заголовок потока данных. Как только ты сможешь ответить внятно на два вопроса: как без файлов отделить твоё любимое порно от образа ядра и нахрена оно наддо - появится технология которая решит твою проблему.

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

> Ты точно понимаешь то что там показано, и что такое файловая система?

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

> WinFS, или любая другая FS, вообще не имеет никакого отношения к этому видео бреду маркетологов, которые просто не понимают, о чем говорят.

WinFS в общем случае скорее клей для имеющейся FS, который приклеивает семантику к файлам.

>>или от файлов и документов никуда не уйти? >А зачем от них уходить?

А есть идеи, как из обычных файлов (плоского набора байт произвольного формата) вытащить краткое описание, превьюшку, иконку и нормер телефона автора? Или как это забить в поиск? Или дать команду rm -rf / "author:Dima Bilan"

>А есть идеи, как из обычных файлов (плоского набора байт произвольного формата) вытащить краткое описание, превьюшку, иконку и нормер телефона автора? Или как это забить в поиск? Или дать команду rm -rf / "author:Dima Bilan"

Медиафайлы к этому более-менее приспособлены. А что делать с текстом(odt,txt,pdf)? Выдирать из каждого частоиспользуемые слова и кидать вывод в кеш поисковика?

> Это может аудиопроигрыватель. Зачем мне ещё откуда-то это искать?

А как же другие приложения? Или даешь велосипедный менеджер коллекций в каждое приложение?

> Вот... Для этого неплохо бы сваять отдельный модуль поиска, столь-же "обычный", как и диалог открытия файлов - для унификации этого поиска.

+ еще обучить приложения работать с таким поиском (сами искалки уже есть).

+ еще обучить приложения работать с дополнительными данными файла, как делают теже проигрыватели с отображением тегов, фоток исполнителей, обложек альбомов и так далее, что совершенно велосипедно и не unix-way. В семантичном десктопе велосипеды будут не нужны - все будет на уровне ОС, в результате чего можно будет просмотреть теги/обложки из практически любого приложения.

> Документы - тут уже можно попытаться организовать поиск по содержимому, но эта штука будет жрать немало ресурсов... За ссылки на модели поиска по тысяче plain-text документов, к примеру, буду благодарен.

Индексаторов и так навалом, да толку пока от них мало.

> Осталось создать директории ~/{Audio,Foto,Video,Doc} и абсолютно все пользовательские документы кидать туда для удобства. А может и нет.

А вот куда скидывать фотки с прошедшей пьянки? В ~/Foto/Pyanka20090406/ ? Или рассовать их по ~/Doc/Contacts/{Lena,Dima,Alex}/Photos/ ? А может по ~/Foto/{koster,vodka,draka}/ ? При любом варианте помойка не исчезает, а только переходит на уровень ниже.

И как все это не организуй - теряются связи между данными. Т.е. взяв произвольную фотку я уже не могу найти оставшиеся, например, с конкретным человеком или местом. Я не могу найти сопутствующую информацию, т.е. мне надо руками лезть в ~/Doc/Contacts/{Lena,Dima,Alex}/email.txt, дабы нужным людям отправить сообщение.

А в случае семантического десктопа достаточно клацнуть на фотку, выбрав "написать письмо", после чего открывается почтовик с заполненным полем "почтовый адрес" - можно сразу граби^Wписать сообщение.

>Или даешь велосипедный менеджер коллекций в каждое приложение?

А много таких приложений? Давай представим Gimp: как эта семантическая информация там может использоваться?

>В семантичном десктопе велосипеды будут не нужны - все будет на уровне ОС, в результате чего можно будет просмотреть теги/обложки из практически любого приложения.

За это отвечает файлманагер, разве нет? Мы можем открыть файл, редактировать его, и закрыть. Также, мы можем использовать его метаинформацию(дополнительные аттрибуты и связи с другими файлами). Что ещё?

>А вот куда скидывать фотки с прошедшей пьянки? В ~/Foto/Pyanka20090406/ ?

Нет. У нас есть /home/emstudio/foto, а в ней тысячи фото. Каталогизацией должен заниматься тот самый уровень абстракции(как WinFS). Пользователю нужно будет работать с программой, не с файлами на винте. А представить эти самые файлы - работа софтины.

>А в случае семантического десктопа достаточно клацнуть на фотку, выбрав "написать письмо", после чего открывается почтовик с заполненным полем "почтовый адрес" - можно сразу граби^Wписать сообщение.

Можно создать контакты для каждого из знакомых, и руками всё дописывать. Но это долго и нудно, верно? Есть ли рабочие реализации распознавания тех-же лиц.. Даже если и есть, то каков процент ошибок?

Неясен момент получения метаинформации - кто займётся распределением документов?

//ну да, много вопросов :)

> Медиафайлы к этому более-менее приспособлены. А что делать с текстом(odt,txt,pdf)? Выдирать из каждого частоиспользуемые слова и кидать вывод в кеш поисковика?

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

Для справки: NTFS для каждого файла хранит набор аттрибутов. У каждого аттрибута есть номер или имя. ЕМНИП, 0x10 - это базовые аттрибуты файла, 0х50 - данные подсистемы безопасности, 0х80 - тело самого файла. Подробнее в LinuxNTFS (я брал их спеки для написания читалки NTFS). Прикол в том, что тело файла не имеет каких-то дополнительных привелегий, это такой же аттрибут как и все остальные, а самих этих аттрибутов может быть множество, т.е. в одном файле может лежать звук/видео/фото/текст/почтовые адреса/логи и т.д., нужно только знать имя файла + номер/имя аттрибута для доступа к ним. Сейчас правда все это практически не используется - уже 10 лет нету инфраструктуры для всего этого, исключением являются некоторые антивирусы, которые подписывают каждый файл.

Это так, для справки.

> А много таких приложений?

rpm -qa | wc
1930 1930 38853

> Давай представим Gimp: как эта семантическая информация там может использоваться?

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

> За это отвечает файлманагер, разве нет?

И давно файлменеджер (не считаем кеды + непомук) показывает видео/играет музыку/показывает теги и все остальное?

> Пользователю нужно будет работать с программой, не с файлами на винте. А представить эти самые файлы - работа софтины.

А может пользователь должен работать с данными, а что они распиханы в файлы - дело десятое?

> Есть ли рабочие реализации распознавания тех-же лиц.

Есть, даже были продажи. См. ноут, которому фотку владельца показывали.

> Неясен момент получения метаинформации - кто займётся распределением документов?

Пользователь + источник происходжения + внетреняя основа самого файла

Скинул я 100 фоток с флешки, каждой дал метку "пианка от 20090406", "участники Lena/Dima/Alex", а пока просматривал - расставлял теги. Это не долго, особенно если фотки рассматривать, а не просто сбросить на винт "до лучших времен".

>А я вроде упоминал, что файлов как таковых не будет? Будет тебе некоторый документ "в сфкрическом вакууме" с кучей дополнительных полей, которые ты сам заполняешь/автоматически заполняются.

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

Как тебе такой вариант: на каждого знакомого есть запись(контакт), в оную мы записываем его мыло, жаббер, имя, фамилию, прочее... при копировании/первом открытии того-же фото мы руками устанавливаем соответствие <фото - контакт> ??

> при копировании/первом открытии того-же фото мы руками устанавливаем соответствие <фото - контакт> ??

Если это фото еще без тегов (наш знакомый не заполнил), то именно так, руками. Реализация - через контекстное меню/драг-н-дроп из ленты контактов/обертку на шелле - дело вкуса.

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

Поддерживаю. Но mp3 - это звук, не картинка. Изврат в виде я каждый формат(а они останутся?) файлов могу рисовать кажется бредовым и нереализуемым.

>И давно файлменеджер (не считаем кеды + непомук) показывает видео/играет музыку/показывает теги и все остальное?

Это можно сделать, раз. А два - почему нет?

>А может пользователь должен работать с данными, а что они распиханы в файлы - дело десятое?

И я о том.

>>сть ли рабочие реализации распознавания тех-же лиц.

>Есть, даже были продажи.

Не верю в способность оной верно распознать лицо под гримассой :) Это придётся делать руками. Или я неправ?

>Скинул я 100 фоток с флешки, каждой дал метку "пианка от 20090406", "участники Lena/Dima/Alex", а пока просматривал - расставлял теги. Это не долго, особенно если фотки рассматривать, а не просто сбросить на винт "до лучших времен".

Поддерживаю, так постом выше и описал.

Важно то, что это делается руками. И тратит время.. %)

> А я вроде упоминал, что файлов как таковых не будет? Будет тебе некоторый документ "в сфкрическом вакууме" с кучей дополнительных полей, которые ты сам заполняешь/автоматически заполняются. Как это сделано в doc, и интегрировано в оболочку ИЕ. Или на маках (точно не скажу - видел только на скриншотах). Только сейчас это сделано в виде костыля, поскольку завязано на конкретные приложения, на конкретные реализации. А когда это будет реализовано на уровне ОС/ФС, то даже обыкновенный txt будет иметь эту информацию.

* Откуууудааааа эта информация будет? Парсер txt файлов с выдиранием из них атрибутов на уровне ФС будет?

* Если каждый документ в вакууме, как будет дело с уникальностью полей? Будет какой-то метод однозначно указать на документ? (при условии что по диску раскидано 15-20 его вариантов в разных редакциях, включая тупиковые ветки которые имеют более поздние даты, но нам не нужны)?

* Если нет каталогов, как группировать файлы? Сейчас даже самые неорганизованные могут создать каталог и туда сваливать весь шит имеющий отношение к одному проекту, чем достигается минимальный порядок. В твоем случае документов в вакууме, что будет? Что-то вроде жизни на системе после выполненного find ~ | xargs -i mv {} ~/`uuidgen` ?

* Каким способом задавать местоположение файла (или кучи оных) - быть им на диске/флешке/в сети?

> Для справки: NTFS для каждого файла хранит набор аттрибутов. У каждого аттрибута есть номер или имя. ЕМНИП, 0x10 - это базовые аттрибуты файла, 0х50 - данные подсистемы безопасности, 0х80 - тело самого файла. Подробнее в LinuxNTFS (я брал их спеки для написания читалки NTFS). Прикол в том, что тело файла не имеет каких-то дополнительных привелегий, это такой же аттрибут как и все остальные, а самих этих аттрибутов может быть множество, т.е. в одном файле может лежать звук/видео/фото/текст/почтовые адреса/логи и т.д., нужно только знать имя файла + номер/имя аттрибута для доступа к ним. Сейчас правда все это практически не используется - уже 10 лет нету инфраструктуры для всего этого, исключением являются некоторые антивирусы, которые подписывают каждый файл.

На маке тоже такая дрянь есть. И в случае мака, и в случае NTFS это неперевариваемо. Как такой многопотоковый файл переписать на флешку? Скачать по HTTP? Перетащить с Мака на NTFS и обратно? На маке есть спец-архиватор, который понимает все эти потоки, и его неиспользование было обычными граблями, пока все не забили на все потоки кроме главного.

Замена "имя файла" на "имя файла + номер/имя аттрибута" - это УГ. Это ты секретарше теперь будешь объяснять что такое поток 0x80?

> Поддерживаю. Но mp3 - это звук, не картинка. Изврат в виде я каждый формат(а они останутся?) файлов могу рисовать кажется бредовым и нереализуемым.

1. А зачем нам сохранять формат?

2. В амиге были реализованы трансляторы, которые практически этим и занимались: преобразовывали определенные типы файлов в "базовые" типы вроде картинок/звуков. Своеобразные кодеки для любых типов файла. Если брать кальку с DirectShow/GStreamer, то там еще можно увидеть и конверсию данных из одного типа в другой. Так почему не написать набор кодеков "из всех форматов во все"?

> Это можно сделать, раз. А два - почему нет?

Ну примерно этим я и занимаюсь :)

> Не верю в способность оной верно распознать лицо под гримассой :) Это придётся делать руками. Или я неправ?

Увы, подробнее не скажу

> Важно то, что это делается руками. И тратит время.. %)

Ну не так уж и много тратит времени. Потом это окупается при поиске, при просмотре "родственных" документов. Если времени нет - всегда можно сделать пачку аттрибутов "все в куче", все равно ее потом проще разбирать. Да и скажи, как сложно (сколько времени займет) сверху экрана расположить ленту контактов, а в нижней прокручивать фотки, перетаскивая контакты на них? А офисный работник вообще часами будет только этим и заниматься :)

> Потому ему не нужны теги и абстракции, он сейчас хочет найти веселую песенку, которая играла на прошлой вечеринке, а как называется, он не помнит, и тегов не помнит, ну вот ту, где ты-ды-дым ты-ды-дым вначале, а потом девушка поет.

Я так нашёл половину своих любимых записей. Главное не стесняться, когда спрашиваешь. ;)

Вторую пловину на гитаре подбирал и выкладывал на опознание...

> А тут только libastral.

Интернет и люди оно называется.

> * Откуууудааааа эта информация будет? Парсер txt файлов с выдиранием из них атрибутов на уровне ФС будет?

В том числе. man strigi, например

> * Если каждый документ в вакууме, как будет дело с уникальностью полей? Будет какой-то метод однозначно указать на документ? (при условии что по диску раскидано 15-20 его вариантов в разных редакциях, включая тупиковые ветки которые имеют более поздние даты, но нам не нужны)?

Версионирование также на уровне ФС, имена у файлов никто отбирать не собирается (наоборот, можно сделать как в п2п - показывать все предыдущие имена файла). Если пользователь сохраняет еще 1 документ пож существующим именем - ему предлогают заменить файл или придумать новое имя (хотя тут еще надо подумать), причем старые версии файла по прежнему доступны в системе версионирования.

> * Если нет каталогов, как группировать файлы? Сейчас даже самые неорганизованные могут создать каталог и туда сваливать весь шит имеющий отношение к одному проекту, чем достигается минимальный порядок. В твоем случае документов в вакууме, что будет?

Нет, просто вместо каталогов будут теги. Вместо скидывания в 1 большую помойку на каждый файл лепится свой тег. После чего в любой программе можно написать tag:project1 и получить все файлы от этого проекта. Могут быть совместные файлы из разный проектов, как сейчас существуют симлинки.

> * Каким способом задавать местоположение файла (или кучи оных) - быть им на диске/флешке/в сети?

В сети (если имеем в виду http) давно уже нету файлов, все работает через незримые трансляторы URL, а диск/флешка представляются банальным "моим компьютером" и "переносным хранилищем", между которыми доступно копирование/перемещение. Причем поиск может быть выполнен и по отключенным "хранилищам", например, базе CD/DVD, система просто спросит "проиндексировать ли?", и если так, то при открытии файла просто попросит нужный диск.

> На маке тоже такая дрянь есть. И в случае мака, и в случае NTFS это неперевариваемо. Как такой многопотоковый файл переписать на флешку? Скачать по HTTP? Перетащить с Мака на NTFS и обратно? На маке есть спец-архиватор, который понимает все эти потоки, и его неиспользование было обычными граблями, пока все не забили на все потоки кроме главного.

А это потому, что софт для этого пока не готов, иначе бы эту фишку включили в винде еще 10 лет назад, когда она только там появилась. Собственно, если верить википедии, была даже бета-версия, но из-за несовместимости с софтом это убрали.

> Замена "имя файла" на "имя файла + номер/имя аттрибута" - это УГ. Это ты секретарше теперь будешь объяснять что такое поток 0x80?

Это на техническом уровне. На уровне пользователя - это файл "Сестренка лена на природе" и пути "Сестренка лена на природе/почта" + "Сестренка лена на природе/телефон"

> Это на техническом уровне. На уровне пользователя - это файл "Сестренка лена на природе" и пути "Сестренка лена на природе/почта" + "Сестренка лена на природе/телефон"

Да, добавлю. Если у "фотки" есть номер телефона, то в "папке" "моя телефонная книга" тоже появился этот файл, но уже не в виде превьюшки, а в виде номера телефона. Если эта фотка имеет метку GPS, то она появится в папке "моя карта" в виде маркера, а если у фотки есть дата, то она будет еще и в папке "мой календарь". Аналогично и со всеми другими объектами.

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

>А зачем нам сохранять формат?

>Так почему не написать набор кодеков "из всех форматов во все"?

С некоторыми ограничениями: не стоит забывать о конечном представлении документа - звук рисовать не надо - его нужно слушать ;)

>Увы, подробнее не скажу

Посему много ручной работы.

Мы можем прикрутить "метки"(как в Nepomuk'е) к каждому файлу + связи с другими объектами. Это даст возможность делать запросы наподобие "месяц+год"+"человек". Что, несомненно, удобная фича.

Меня волнует вопрос обратной совместимости: у приятеля винда и нам нужно скинуть ему фотки со вчерашнего похода. Мы можем кинуть файл <дата><парачка_тегов>.png, можем кинуть просто файл, а можем прикрепить теги отделиным архивом в директории с фотками. Как лучше?

Вроде общие вопросы закончились...

Где-нибудь можно посмотреть на roadmap?