[music] Каталогизация

> У тебя есть 3 задачи: хранение музыки, доступ к музыке и организация музыки. Они вообще слабо связаны, ФС решает 1ю и частично 2ю так,

чем отличается "логическая организация" и "хранение"? это одно и то же, объекты/файлы те же самые, просто пути разные: или исторический из ФС (1) или логический из фолксономии (3). Логический путь, это как URL, другой адрес того же объекта. А файл может скачаться например через прокси, из другого приложения, и т.п.

> Зачем тебе на уровне конечного пользователя знание о ФС вообще?

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

>Вопрос -- откуда должна браться информация о том, как раположить в ФС твои файлики? Из астрала? Нет, не подходит....

> Думаем дальше. Ах да, из тегов! Жанр, исполнитель, год, альбом, номер и название трека... Что еще нужно для полного счастья?

добавь новый тег "настроение", "блондинка, с которой я чятился под эту музыку". Всё, стройная система каталогизации MP3 тегами накрылась, ибо не расширяема.

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

> Потом, СУБД не любят операции "удалить".

но есть отношение логической связности в СУБД. Удалять с GUID-подобными первичными ключами и не понадобится, просто по какому-то "демону отношений" ссылка (и транзитивные по ней) станет недоступна.

> Какую задачу ты этим решаешь?

унифицируемости наименований (фолксономии), вестимо.

> Вот есть у тебя 1 СУБД и одно кривое приложение

ОК, сделаем не одну СУБД. Сделаем распределённую СУБД с БД, каждая из которых логически связана, доступна по ссылкам с другими, более удобными для каждой задачи базками.

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

ещё смешнее ^W печальнее вышло с Райзером: он свою ФС с тегами/категориями/плагинами под приложение как раз и позиционировал для поисковых движков. Вроде они какой-то поисковый движок сделали (корпоративный, похоже, раз не слышно)

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

в плане хранения -- наверное. В плане логического наименования полезно было бы.

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

ссылки глобально-уникальны в пределах одного накопителя (как иноды), разные пространства имён. Но это физические ссылки, логические объединяют по логическим namespaces (или указывают в снапшоты lvm/btrfs/...).

> "табличная БД" = -1,

http://www.rashkovskii.com/2008/05/we-dont-need-a.html

> чем отличается "логическая организация" и "хранение"

Тем, что логическая организация - вещ динамическая. Как сегодня удобно, так и организовал и вообще у меня 4 шаблона. А ФС занимается хранением - попросили файлик - отдала файлик.

> и в каждом приложении свои теги.

В каждом формате + расширенные в приложении, например, количество прослушиваний трека.

> но есть отношение логической связности в СУБД. Удалять с GUID-подобными первичными ключами и не понадобится, просто по какому-то "демону отношений" ссылка (и транзитивные по ней) станет недоступна.

А освобождение ресурса, занимаемого стираемым?

>> Какую задачу ты этим решаешь?

> унифицируемости наименований (фолксономии), вестимо.

И кому нужно решение этой задачи? Явно не пользователям. И не программистам.

> добавь новый тег "настроение", "блондинка, с которой я чятился под эту музыку". Всё, стройная система каталогизации MP3 тегами накрылась, ибо не расширяема.

На уровне приложения расширяема. Да, при переходе с приложения на приложение информация потеряется, ну и не страшно по большому счету.

у меня ~/music/artist/#alb - album (year)/#tr - track

Для проигрывания - mpd. Музыки довольно много, больше 30k треков, все теги заполнены.

Централизованное хранение баз данных, хорошо это или плохо?

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

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

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

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

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

Примерно как-то так...

Согласен в таком виде. Вижу только 2 проблемы:

1 - реализация. Все-таки текст, картинки, фильмы и музыка хранятся очень по-разному и втройне по-разному если мы хотим их редактировать с историей изменений.

2 - пользователи. Будет ли это востребовано? Многие ли из нас хотя бы музло в человеческий вид привели? И вообще, это надо?

Да и... Есть ведь еще 1 подход - слабосвязные элементы. Ну вот слушаю я KMFDM, а LastFM мне показывает про них из википедии без всяких глобальных СУБД.

1 - Как-бы да, но поэтому и мысль о именно файловой сиситеме. Когда при переносе например с одной ФС на другую файл перенесётся с полным путём обозначающем поля БД а сам файл - это просто одно поле с бинарным содержанием. При переносе полного пути соответственные поля на новом месте создадутся.

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

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

2 - Тоже да, но как-бы наличие Кати Лель и Димы Билан не делает избыточной библиотеку Максима Мошкова. Кому-нибудь наверное надо, кому-то нет.

3 И, да, интернет. Но сеть - это сеть узлов, сеть без узла - ничто. После выхода на новый уровень интергации информации и сеть изменится. Сменятся протоколы... Протокол передачи сюжета...

В моей голове дерево ФС выкорчевал недавно знакомый при разговоре. Файлы лежат в виде последовательности байт. В таблице расположения файлов (в каждой ФС есть свой fat...?:) хранятся адреса. Путь там - только дополнительная информация которая где-то хранится и которая нужна для чьего-то удобства. Положим все файлы в один каталог. И прицепим к ним теги или как это их там... служебную информацию. Готово?

> А освобождение ресурса, занимаемого стираемым?

сборщик мусора.

>> унифицируемости наименований (фолксономии), вестимо.

> И кому нужно решение этой задачи? Явно не пользователям.

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

> И не программистам.

установщик инсталлятор/пакетный менеджер натыкается на ту же проблему с тегами/фолксономией, только теги здесь -- параметры системы сборки, "замаскированность" пакета, USE-флаги, и т.п. Вот папки-бандлы в вашей родной макоси рулят -- потому что это самодостаточная сущность, с метаданными, структурой и элементами. Это те же самые метаданные, та же самая задача "в общем виде".

> Да, при переходе с приложения на приложение информация потеряется, ну и не страшно по большому счету.

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

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

+1. Правда база может оказаться не реляционной, но важно само наличие связи (пути в "логической ФС" аналогично URL), ссылок, косвенности по ссылкам, следу, по которому доступна эта связь.

> Есть ведь еще 1 подход - слабосвязные элементы. Ну вот слушаю я KMFDM, а LastFM мне показывает про них из википедии без всяких глобальных СУБД.

ну то есть само наличие связи между элементами, полиси важнее конкретного механизма (СУБД или last.fm или википедия, или смена статуса контакта в чати).

> Положим все файлы в один каталог. И прицепим к ним теги или как это их там... служебную информацию. Готово?

http://los-t.livejournal.com/16400.html (описание репозитория git)

gitwiki, см. http://atonie.org/2008/02/git-wiki

wiki в файлах, хранение в git. См. также ссылку на применение git:
http://www.advogato.org/person/apenwarr/diary/371.html

а сам обычный файл вида /путь/.../файл или /категория/тег1+тег2-тег3/#ссылка пусть будет ссылкой на такие файлы-блобы. Второй путь с категориями можно вычислять "лениво", вроде URL или пути в /proc/pid/fd/N , нужно просто расставлять нужные ссылки, которые однозначно определяются по "логическому пути" .
И если на то уж пошло, файл на диске -- это набор блоков на /dev/sdaN. А объект в приложении, сериализованный из файла -- это набор блоков в /dev/kmem = /proc/pid/mem/... . Почему представления разные, и чего можно достичь унификацией представлений? из 64-битового адреса в ОЗУ получится хороший GUID/inode.

> 2 - Тоже да, но как-бы наличие Кати Лель и Димы Билан не делает избыточной библиотеку Максима Мошкова. Кому-нибудь наверное надо, кому-то нет.

теги в разных/одинаковых пространствах имён, пространства имён как множества, объединение/пересечение множеств

> описание репозитория git

Строить велосипед нет большого желания. В карманных революциях проку мало. Пусть утопия пока остаётся утопией... :)

>http://los-t.livejournal.com/16400.html (описание репозитория git)

или вся серия по "логическому ФС адресу" http://los-t.livejournal.com/tag/git+guts -- это ведь запрос, вместо git+guts может быть другой тег, вместо ns://URL/tag/.. может быть другой сервис имён (например, адрес статьи в кеше squid'а)

зря, а я думаю, кто бы вот скрестил gitfs + LISFS (LogicFS из inria.fr) для этой задачи.

Ну у меня для такой карманной революции ни сил ни умений на хватает :)

у меня зато идей и концепций навалом.
Бороду уже сбрил, а уми^U тоже думал на эту тему -- это было бы полезно на 2х уровнях, что системным про который я тут распинаюсь, что для приложений в виде какой-то mysqlfs :)

Если что-либо подобное существует в каком либо реальном проекте, может быть лучше включиться?

Я года 3 назад видел концепт именно такой как ты хочешь системы, даже постил про нее скрин. Убей не помню ни названия, ни темы.

http://www.linux.org.ru/view-message.jsp?msgid=837640 еле нашел!

Xanadu тоже интересно, в эту же тему. Описание AUGMENT (NLS) Дуга Энгельбарта тоже -- там про ссылки второго и выше уровня косвенности, ссылки на абзац/на содержимое, которые не сыпались если контент изменялся (примерно как вики-ссылки). Плюс это реально работающий гипертекст, в отличие от "бумажного" Xanadu Теда Нельсона.

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

Всем спасибо!

easytag , не побоюсь этого слова, рулит и даже немножечко педалит.

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

конечно, спасибо, попробую сегодня же