LINUX.ORG.RU

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


0

0

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

Собственно изначальная идея была - добавление мета-данных в ЛЮБЫЕ файлы. В т.ч. и те, в которых ничего такого нет (типа TXT например). Чтобы ЛЮБАЯ программа с минимальными усилиями могла понять, с чем имеет дело, без встроенной поддержи тысячи и одного формата. Этакая общая обёртка. В идеале - на уровне системы. Т.е. если программа знает такой файл, то работает с ним как хочет. Если не знает - ос просто при открытии отдаёт ей только поток "по умолчанию"

Немного развив:

Не секрет, что ныне существует туева хуча файлов с внутренней фс или её аналогом..
С ходу вспоминаются wad, psd, exe(pe), jpg, tiff, mp3, doc, xls, mdb, odf, avi, ogg, образы дисков, архивы и т.д.
Собственно идея - сделать полностью универсальный формат файла с внутренней фс. Или считать файл архивом с простейшай структурой (т.е. файлы не сжаты, цельны. если ресурсов хватает - можно и жать)

Добавить туда поддержку каталогов. Ресурсы файла хранить не в ехе, а внутри архива отдельными файлами. Туда-же добавить мета-данные, mime-тип, описание, и пр...
Указать там поток "по умолчанию". т.е. если запускать файл, то запускается именно конкретный файл из архива.. Там-же можно отдельным файлом добавить список известных программ, которые этот формат понимают, например. Т.е. если такой файл у тебя не прописан, но есть одна из этих программ - то откроется он ей.. и т.д.
Возможностей море.
В запускаемых файлах можно хранить альтернативные куски кода для разных платформ, причём в варианте, например - win-exe + elf + java + perl-script

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

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

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

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

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

anonymous ()

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

#!/usr/sh

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

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

anonymous ()

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

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

berrywizard ★★★★★ ()

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

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

ugoday ★★★★★ ()

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

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

anonymous ()
Ответ на: Re: Универсальный формат файла от anonymous

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

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

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

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

TripleGluk ()
Ответ на: Re: Универсальный формат файла от ugoday

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

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

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

TripleGluk ()
Ответ на: Re: Универсальный формат файла от berrywizard

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

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

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

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

TripleGluk ()
Ответ на: Re: Универсальный формат файла от TripleGluk

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

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

> Чем?

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

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

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

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

watashiwa_daredeska ★★★★ ()
Ответ на: Re: Универсальный формат файла от watashiwa_daredeska

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

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

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

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

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

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

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

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

TripleGluk ()
Ответ на: Re: Универсальный формат файла от TripleGluk

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

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

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

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

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

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

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

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

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

watashiwa_daredeska ★★★★ ()
Ответ на: Re: Универсальный формат файла от TripleGluk

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

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

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

AiLr ★★ ()

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

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

sskirtochenko ★★ ()
Ответ на: Re: Универсальный формат файла от sskirtochenko

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

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

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

TripleGluk ()
Ответ на: Re: Универсальный формат файла от AiLr

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

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

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

TripleGluk ()

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: Re: Универсальный формат файла от anonymous

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

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

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

anonymous ()
Ответ на: Re: Универсальный формат файла от wfrr

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

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

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

TripleGluk ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.