Универсальный формат файла

>Были мысль сделать это на базе ФС (помнится ntfs потоки поддерживает) но про переносе на др. фс всё терялось..

Алтернативные ФС шерифа не волнуют. Все основные это поддерживают.

http://en.wikipedia.org/wiki/Extended_file_attributes

К чему это все?

Примитив. Не универсально и неудобно.

#!/usr/sh

всё уже давно придумано

да и не надо это

man file

усложнение сущностей. зачем создавать ФС внутри файла, если она уже есть снаружи?

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

до сих пор с LITTLE / BIG ENDIANs не определились, а вы - такое универсальным и стандартным сделать хотите... ИМХО да и нафиг оно не надо - к чему фирмварь на фирмварь наворачивать? Стремиться следует к простоте и эффективности.

>Алтернативные ФС шерифа не волнуют. Все основные это поддерживают.

Спасибо. Про FAT не знал.

>Стремиться следует к простоте и эффективности.

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

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

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

Например определять тип файла, пытаясь проанализировать неизвестную структуру - более эффективно?

>man file

если не ошибаюсь - возвращает тип файла. не более того.

>всё уже давно придумано

подробнее плз?

>Примитив.

Я не предлагаю готового решения. Пока вопрос идеи в целом.

>Не универсально

Чем?

>и неудобно.

как есть - удобнее?

>зачем создавать ФС внутри файла, если она уже есть снаружи?

Однако сейчас существует прорва форматов с ФС внутри...

Да, единственная адекватная альтернатива - цеплять файлы-спутники...

>>Не универсально

> Чем?

Шелл с пайпами, например. Как передавать метаинфу? А если она меняется? Например, на входе -- text/plain, на выходе -- text/html. А как быть с метаинфой об авторстве в этом случае? А как насчет личных расширений схемы метаинформации?

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

> как есть - удобнее?

Да. Отсутствуют лишние сущности, что упрощает работу в большинстве случаев. В случаях, когда нам действительно нужна только метаинформация, есть расширенные атрибуты современных ФС. В случае сложной файлосистемоподобной структуры файла есть много чего, например, zip (см. ODF) или образ файловой системы (см. initrd). Нафига городить zip для простого plain/text?

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

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

Аттрибуты ФС, к сожалению:
1. поддерживаются не всеми фс (таки для FAT не нашел)
2. если программа о них не знает - при копировании они пропадут
3. почти гарантированно пропадут при пересылке файла по сети

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

Вот о том то и речь, что существует слишком много чего для решения, вобщем то, одной и той-же задачи.. Кстати я не утверждал, что это д.б. какой-то новый формат. Можно хоть тот-же zip. Кстати zip для простого plain/text городит примерно -70% размера файла. :)

Что-ж, нет, так нет.

ЗЫ: Только что вспомнил, что в вынде таки есть(не совсем на таком уровне) встроенная поддержка файлов со стандартной встроенной ФС. В часности офисные файлы её используют.

> 2. если программа о них не знает - при копировании они пропадут

Цитирую тебя же:

> Если не ожидает - только данные из него, благо формат на это и рассчитан.

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

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

> вариантов много.. Тут уже засисит от конкретного содержимого файла. Но по идее, часто должны быть простые но не совсем мелкие. Например тот же ODF: текст с форматированием, табл стилей, картинки...

Я не это имел в виду. zip -- это файл, в него запакованы другие файлы. Его можно распаковать и получить эти файлы. Ибо все элементарно просто: файл -- это упорядоченная последовательность байтов, файл+файл=файл и прочие маленькие радости. Если же твой "универсальнй" формат -- единственный, то файл -- это совокупность метаинфы и других файлов, которые представляют собой... что? И что получится, когда "распаковывается" файл-архив?

И, главное, ради чего? Скольки процентам софта и файлов нужна эта самая метаинфа? И ради этого напрягать всех?

Мы явно друг друга не понимаем..
Ладно. Нет, так нет.

А я, видать, понимаю - у меня была аналогичная идея, только более общая. Реализовать можно как proof of concept в виде самостоятельной среды - типа Squeak, Inferno, ибо иначе это будет корявым нагромождением костылей.

В моем представлении, это будет уже не ФС, а полноценная БД; хочется отказаться от чисто иерархической структуры в пользу иерархической системы тэгов. Вместо файлов ес-но будет нечто наподобие алгебраических типов. Потом, никакого изменения состояния - только через встроенную VCS. Далее еще можно прикрутить децентрализованный P2P движок типа P-Grid и радоваться жизни =)

Может быть нужно универсальную программу, которая все понимает. Эдакий философский камень в кремниевом.

xml не нужен, копай в сторону s-exp

>Может быть нужно универсальную программу, которая все понимает. Эдакий философский камень в кремниевом.

Не, универсальная програма - абстракция. Количество возможный дайствий растёт в геометрической прогрессии с ростом количества объектов. Собственно вся идея как раз заключалась в упращении разработки своего, необходимого в данный момент софта. Зачастую гораздо проще и быстрее можно сварганить свою софтину для конкретных целей, чем пытаться разобраться в огромных полнофункциональных модулях, из которых потом будет использоваться 1..2 функции или искать программу, которая умеет то, что тебе нужно. Очень часто таковой либо нет, либо воспользоваться ей слишком сложно (например умеет, но только по одному и руками)

>В моем представлении, это будет уже не ФС, а полноценная БД;

А можно поподробнее? Была мысль про БД в своё время. (да и у кого её не было:) вспомнить хотя бы Win_FS) Система тэгов имеет свои плюсы в плане поиска, но речь опять не об этом. Суть идеи - упрощение доступа к содержимому файлов и возможность добавлять туда сущности. Хранение дополнительной инфы на базе ФС не решает проблемы доступа и решает проблему дополнения ТОЛЬКО в пределах текущей ФС. При передаче файлов всё лишнее едёт лесом. А P2P движок зачем?

>xml не нужен, копай в сторону s-exp

Да его, вроде, и не упоминали даже.

s-exp - что за зверь? Поиск не рулит.

Народ, не тормозите. Хотя по такому сумбурному объяснению есть полное право ничего не понять: я и то понял идею только после устного обсуждения. Сча по полочкам разложу.

1). Что предлагается? Универсальный формат контейнера (УФК). Т.е. файл-контейнер, содержащий в себе другие файлы, формат которого был бы унифицирован и общепринят.

2). Его свойства. Он имеет компактный хедер (чтобы не раздувать объем на мелочи) и опционально поддерживает небольшое быстрое сжатие (для контейнеров, в отличие от архивов, актуальна обычно скорость компрессии-декомпрессии, а не крохи разницы в сжатии).

3) Какие форматы он потенциально заменяет? Серию графических (.jpg, .tiff и т. д.; даже помимо метаинфы, они и сами состоят из нескольких ресурсов, некоторые из которых сжаты. Так, JPEG состоит из таблицы квантования и данных, сжатых по Хаффману). Серию документных (.doc, .xls и иже с ними) Серию полу-универсальных контейнеров (.ogg, .avi и т. п.) Серию специальных форматов (.wad и прочие игродельские творения). Исполнимые файлы (которые давно состоят из отдельных кода и ресурсов, причем код можно хранить в нескольких версиях под разные платформы).

4) Какие форматы он заменяет, но делать этого не стоит? Архивы. У них лучше сжатие и они постоянно развиваются, а наш УФК чем реже трогаешь, тем лучше.

5) Экологическая ниша этого типа файлов. Эти файлы применяются там, где набор ресурсов представляет собой единый неразъемный пакет. Если ресурсы имеет смысл часто разъединять, имеет смысл просто положить их в один рабочий каталог. Если ресурс не разделяется на осмысленные части, его проще хранить одним файлом "как есть" (например, .c, .bmp, .wav или .raw image).

продолжение сле...

 Народ, не тормозите. Хотя по такому сумбурному объяснению есть полное право ничего не понять: я и то понял идею только после устного обсуждения.
 Сча по полочкам разложу.

 1). Что предлагается?
 Универсальный формат контейнера (УФК). Т.е. файл-контейнер, содержащий в себе другие файлы, формат которого был бы унифицирован и общепринят.

 2). Его свойства.
 Он имеет компактный хедер (чтобы не раздувать объем на мелочи) и опционально поддерживает небольшое быстрое сжатие (для контейнеров, в отличие от архивов, актуальна обычно скорость компрессии-декомпрессии, а не крохи разницы в сжатии).

 3) Какие форматы он потенциально заменяет?
 Серию графических (.jpg, .tiff и т. д.; даже помимо метаинфы, они и сами состоят из нескольких ресурсов, некоторые из которых сжаты. Так, JPEG состоит из таблицы квантования и данных, сжатых по Хаффману).
 Серию документных (.doc, .xls и иже с ними)
 Серию полу-универсальных контейнеров (.ogg, .avi и т. п.)
 Серию специальных форматов (.wad и прочие игродельские творения).
 Исполнимые файлы (которые давно состоят из отдельных кода и ресурсов, причем код можно хранить в нескольких версиях под разные платформы).

 4) Какие форматы он заменяет, но делать этого не стоит?
 Архивы. У них лучше сжатие и они постоянно развиваются, а наш УФК чем реже трогаешь, тем лучше.

 5) Экологическая ниша этого типа файлов.
 Эти файлы применяются там, где набор ресурсов представляет собой единый неразъемный пакет. Если ресурсы имеет смысл часто разъединять, имеет смысл просто положить их в один рабочий каталог. Если ресурс не разделяется на осмысленные части, его проще хранить одним файлом "как есть" (например, .c, .bmp, .wav или .raw image).

продолжение сле...

 6) Преимущества УФК перед тем, что мы имеем (потоки, "рассыпуха", собственные контейнеры).
 а) Потоки могут поддерживаться только на уровне оси, причем при копировании и пересылке по сети нужны специальные меры для сохранения структуры. УФК может поддерживаться как на уровне оси, так и на уровне прикладной программы, с использованием как стандартных библиотек (статических или динамических), так и самописных (на каком-нибудь микроконтроллере). Копирование УФК не требует никаких специальных мер -- файл и файл.
 б) Потоки нельзя держать на съемном носителе, про который не знаешь, куда завтра сунешь. УФК там спокойно переживет обращение от Win98, DOS, Symbian, PalmOS и напоследок WinCE, а, вернувшись на родину, все так же будет ждать понимающую его программу.
 в) Перед простым складыванием файлов в одну папку УФК имеет преимущество в удобстве обращения, копирования, с ним сложнее запутаться и много мелих файлов не оставляют хвосты кластеров. Сжатые ресурсы имеют один общий хедер, а не по одному на каждый, что увеличивает эффективность компрессии.
 г) Преимущество перед сонмом отдельных контейнеров в том, что не нужно загромождать прикладное ПО работой с этими контейнерами. УФК, как правило, будет сидеть на уровне оси, за исключением фотоаппаратных прошивок и олдскульных промышленных осей типа ОпенДОС, где принято делать все на уровне прикладной проги.
 д) Второе преимущество перед отдельными контейнерами в том, что форматы пожатых по УФК файлов легче расширять, подкидывая туда те типы ресурсов, которые вам нужны -- все равно что в архив положить. Программы, не понимающие их, просто к ним не обращаются, т. к. не знают об их существовании. Их не надо отдельно пропускать.
 е) Третье преимущество перед отдельными контейнерами состоит в том, что неподдерживаемую "мету" (например, HTML-инфу об авторе внутри .MP3 вместо привычной .TXT-инфы) можно посмотреть совершенно посторонней прогой, просто как в архиве.
 ж) Четвертое преимущество перед отдельными контейнерами состоит в возможности кросс-программных вызовов. Не обязательно обрабатывать все ресурсы главной прогой, для которой предназначен формат. Она может просто вызвать другую, которая прочитает этот файл и расшифрует другие ресурсы "по своему профилю". Так, внедренный в документ звук можно играть плеером, а не средствами графического редактора (что намного менее громоздко, чем или отдельная реализация плеера в редакторе, или плеер, имеющий внешний интерфейс для встройки в чужие проги).

 7) Внедрение.
 Очевидно, что для внедрения придется преодолеть колоссальную инерцию. Поэтому внедрение нужно начинать с выработки стандарта (попроще и поуниверсальнее) и поддержки его в новом ПО как можно чаще. Потом само пойдет понемногу, появятся конверторы и система придет в состояние с наименьшей энергией, как всегда.

iso9660 - образ CD, универсальный контейнер, содержит небольшой хедер, может хранить все что угодно.

>Сча по полочкам разложу.

Ага! Именно это я и пытался сказать.

>iso9660 - образ CD, универсальный контейнер, содержит небольшой хедер, может хранить все что угодно.

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