Выжимка из «универсального формата файла» от TripleGluk

...дует:

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

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

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

"детская болезнь левизны" :-). В Microsoft была пандемия где-то в конце 90х, когда они обещали сделать все OLE-документами. Часть из этого работает - вы можете вставлять одни OLE документы в другие, но широкого распространения OLE-формат не получил. Если официальной линии партии^W^W^W мощной группе внутри Microsoft не удалось перестроить весь мир, каковы шансы у вас?

Была такая тема... но, всё-таки, OLE -- не то же самое, что УФК. Он преследует слегка другие цели, да и стройностью архитектуры, мягко говоря, не грешит. В сексе обычно достаточно всего на 4 сантиметра ниже попасть -- и вся работа заканчивается абсолютно бесплодно :) Так что промахи былого -- симптом, но еще не диагноз.

> iso9660 - образ CD, универсальный контейнер, содержит небольшой
> хедер, может хранить все что угодно.
> wfrr (*) (30.12.2007 21:19:12)

 Отвечу в новой теме, хотя ужасно лень отвечать -- ну
совершенно несерьезное предложение. Контейнеризация путем
содержания файловой системы ISO в сыром виде... ну, круче
только хранить в бинарном виде посекторно образ диска,
чтобы для доступа к контейнеру пришлось определять на нем
разделы, в них определять диски, типы FAT и искать там
файлы.
 Хедер -- таки да, небольшой :) Вопрос только, кому от
этого легче... все-таки, ISO -- это образ, а не контейнер.

tar?

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

Очень хотелось бы услышать мнение самого TripleGluk по поводу ТАРа.

> Хедер -- таки да, небольшой :) Вопрос только, кому от этого легче... все-таки, ISO -- это образ, а не контейнер.

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

Любая файловая система на loop-файле.

> всё-таки, OLE -- не то же самое, что УФК.

Озвучте чем именно вы будете отличаться от OLE-шного structured storage. Пока принципиальных отличий не видно. Там тоже есть всякие IPersistStream'ы, IProperties (как вспомню так вздрогну :))) и т. д.

> Он преследует слегка другие цели, да и стройностью архитектуры, мягко говоря, не грешит.

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

> В сексе обычно достаточно всего на 4 сантиметра ниже попасть -- и вся работа заканчивается абсолютно бесплодно :) Так что промахи былого -- симптом, но еще не диагноз.

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

Файловая система... IProperties... У меня растет и крепнет подозрение, что "универсальность" стала синонимом "сложности". TripleGluk в качестве одной из возможных отправных точек видел ZIP. Я вижу WAD. И то, и другое элементарно и давно известно, фишка, на мой взгляд, не в некоей волшебной структуре, а в _правильном применении_ простого и банального контейнера.
Ну, раз я "мертвых маленьких зверушек вам с собою приносил", то "неожиданно для вас я устрою мастер-класс".
Сейчас я напишу отправной вариант структуры, а желающие (включая, ессно, ТроеГлюка) пусть мысленно приложат его к той или иной сфере, "столкнут с реальностью".

в досе используются .три буквы
будем считать это ключём(хэшем) к таблице

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

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

большинству файлов хватает #! в начале и указанию пути запуска программы
дальше можно хранить в виде уже сжатой информации
т.е. заголовок в одну строку и он уже есть

и нехрен придумывать _геморой_ людям

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

p.p.s. каптча losing

man losetup и не нужно изобретать велосипед, все уже придумано до вас и делается штатными средствами. Чем мифический контейнер будет лучше фс в файле? Тем что это было невозможно в милой вашему сердцу ms-dog?

Итак, пусть будет такая структура. Исходил из того, что она намного
чаще читается, чем правится, и скорость важна именно в доступе к
произвольному ресурсу.
Пункт раз -- каталоги не поддерживаются. Смысла нет.
/*заголовок*/
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0 //Этот адрес начала первого ресурса == адрес конца заголовка, т. к. ресурсы в заголовке лежат в том же порядке, что и в теле
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0 //Это все ресурсы
адрес_начала,байт_сжатия, //А вот эти два -- словари для сжатия
адрес_начала,байт_сжатия,
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0 //Этот ресурс сжат
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0 //Этот -- тоже
* * *
адрес_начала,байт_сжатия,"Этоимяфайла.эторасширение",0
/*тело*/
Ресурс1_Ресурс2_Ресурс3_Словарь1_Словарь2_Ресурс4_СжатыйПоСловарю1Ресурс5_Сжаты
йПоСловарю1Ресурс6_СжатыйПоСловарю2Ресурс7...

 Адрес начала записан, адрес конца равен адресу начала следующего
(или концу файла, если последний).
 Байт сжатия бывает 00000000 (не сжат), 1xxxxxxx (ресурс не является
самостоятельным, а является словарем сжатия №ххххххх) и 0ххххххх
(ресурс сжат по словарю ххххххх).
 Словарь должен идти перед сжатым ресурсом (надо, кстати, еще подумать
-- неизвестно, как его быстрее было бы в хедере искать), по одному
словарю может быть сжато любое число ресурсов, словарь не имеет имени.
 Очевидно, всего возможно 127 словарей (1..127) и произвольное количество ресурсов.
 Простенько, похоже на .zip и .wad. Оттолкнемся от этого базиса (а я 3Глюку в аську стукну).

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

Дизайн-понос :-)

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

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

Ну где, где написано, что за цель ставится ассоциирование данных с прогами? Уж, по-моему, чётче, чем я в начале темы по полочкам разложил, написать просто невозможно.
Я понял, что вы имеете в виду... как бы еще объяснить-то, что МЫ имеем в виду %) %)

Как это -- "не определен"? Этому набору весь второй пост посвящен.

Если не ошибаюсь именно так устанавливается софт в DSL (dammn small linux)

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

При нынешних реалиях проще сделать для всех существующих форматов файлов единый интерфейс для чтения-записи метаданных.

Хотя, в кедах, гноме и венде что-то подобное давно есть и работает.

А да, вылетело из головы, zip-архивы по типу JAR и OpenDocument уже и так кругом используются. Вот вам и УФК.

sdio, ero-sennin, большой зачОт :) Ростки этой затеи, естественно, стихийно прорастают в разных областях, и многие почти соответствуют описанной схеме. Чем больше мы их рассмотрим, тем лучше.

> При нынешних реалиях проще сделать для всех существующих форматов файлов единый интерфейс для чтения-записи метаданных.

Вот это уже ближе к делу. что-то вроде file(1) или lesspipe.sh , но чтоб выдавало больше деталей и позволяло редактировать..

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

Какие абстракции поддерживает эта хреновина?
(с файлами, сокетами, потоками, шаренной памятью всё ясно)
Что она упростит/изменит?
Как будет выглядеть API?
Предусматривается ли какая-нибудь обратная совместимость (в API) с тем, что она заменяет?

поздравляю, ты изобрел IFF (Interchangable File Format), как в Амиге и SGI.

>г) Преимущество перед сонмом отдельных контейнеров в том, что не нужно загромождать прикладное ПО работой с этими контейнерами. УФК, как правило, будет сидеть на уровне оси, за исключением фотоаппаратных прошивок и олдскульных промышленных осей типа ОпенДОС, где принято делать все на уровне прикладной проги.

Это было в Амиге и БеОС, там были дататайпы. Дататайп = плагин уровня ОС, "плагин формата файла", который позволяет унифицированно сохранять/изменять/создавать новые файлы/конвертировать в/из других форматов. В Амиге, был один универсальный просмотрщик файлов MultiView (с поддержкой гипертекстов), который понимал все файловые форматы, установленные в системе.

Вышла новая программа, с новым форматом файлов -- написали/установили новый дататайп, после чего все ОСТАЛЬНЫЕ программы стали понимать этот новый формат.

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

> При нынешних реалиях проще сделать для всех существующих форматов файлов единый интерфейс для чтения-записи метаданных.

+1, вместо изобретения "универсального формата файлов" лучше бы повторно изобрели амижные дататайпы (в смысле, API дататайпов; метаданных; способы организации и унификации метаданных).

Сам УФК как мегаконтейнер не нужен, нужна "аннотированная ФС". Если у нас файл физически отображается по нескольким альтернативным путям, и одинаково доступен по любому из них. А некоторые пути являются путями в пространстве других программ, как трансляторы в HURD. Они и разбирают сам формат файла и предоставляют унифицированные, стандартизированные метаданные.

Нужно просто стандартизировать такое API "верхнего уровня" для работы с метаданными, и организовать прозрачный протокол вроде 9P из Plan9 для файлового доступа через плагин-дататайп, в "другой формат" файла.

> Хотя, в кедах, гноме и венде что-то подобное давно есть и работает.

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

Binary XML?

На самом деле формат весьма и весьма распространён под вынь. Хотя ни удобным, ни простым его назвать трудно. M$ очень любит изобретать громоздкие технологии, с которыми потом сама не знает, что делать.

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

>В копилку - еще есть такой формат как dmg

Большинство образов, как я понимаю, копируют структуру диска. С пустотами, служебной инфой и пр. У iso вобще для нормальной работы нужна двойная структура каталогов(8.3+Joliet), что никак не является ни простым, ни удобным. Плюс какие-то заморочки с расширением от cd к dvd (особо подробно не разбирался)

На счёт dmg ничего не скажу. Не удалось найти о нём нормальной инфы. Если есть линк - было бы интересно посмотреть.

>в досе используются .три буквы будем считать это ключём(хэшем) к таблице

Рисширение отнюдь не всегда однозначно указывает на тип файла и примеров тому море. Особенно если учитывать не самые распространённые программы и служебные файлы программ в собственном формате.

>+ в базе можно проверять ещё по дополнительным признакам, эврестический поиск по числу символов, их распределению, сплайсу, фрактальному образу, проекции в торсионном поле или множестве чисел C

Простота методов в действии. Ещё проще - открыть файл hex-вьювером и на глаз определить. Метод тоже весьма действенный но...

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

1. куда указывает эта строка, если такой программы в системе нету? (например попала видюха с новым кодеком.) 2. мне нужно узнать, что там, а не посмотреть кино. Нужно название, саундтрек или титры...

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

В tiff эту проблему вполне решили. в текстах unicode тоже вроде как. Если я правильно понял, в IFF упоминавшемся ниже - тоже. А хедер загадит - так от намеренной порчи спасай не спасай...

>losetup

Не совсем понял, как это поможет. Можно поподробнее?

>Если не ошибаюсь именно так устанавливается софт в DSL

Всё-таки это только часть задачи.

>А да, вылетело из головы, zip-архивы по типу JAR и OpenDocument уже и так кругом используются. Вот вам и УФК.

Помнится я их упоминал ещё в самом начале. Как вариант - вполне может быть.

> При нынешних реалиях проще сделать для всех существующих форматов файлов единый интерфейс для чтения-записи метаданных.

Вопрос - как сделать интерфейс к новому формату, которого система не знает.

>поздравляю, ты изобрел IFF (Interchangable File Format), как в Амиге и SGI.

В целом - да. Суть, вроде как, та же.

>Сам УФК как мегаконтейнер не нужен, нужна "аннотированная ФС". Если у нас файл физически отображается по нескольким альтернативным путям, и одинаково доступен по любому из них. А некоторые пути являются путями в пространстве других программ, как трансляторы в HURD. Они и разбирают сам формат файла и предоставляют унифицированные, стандартизированные метаданные.

Одно другого не исключает. Скорее наоборот - облегчает. Смысл унификачии - иметь возможность работать(ходя бы частично) с файлами, которых система НЕ ЗНАЕТ. Т.е. программы, которая работала бы с ними в полном объеме в системе нет.

А уж через апи или ещё как- это дело вкуса. Хотя при наличии стандарта - апи сделать не проблема.

>Binary XML

Как то слшком замороченно и, вроде, ориентированно на девайсы с мизерными ресурсами (телефоны и пр.)

> Вопрос - как сделать интерфейс к новому формату, которого система не знает.

угу, это действительно нужный вопрос. Какой интерфейс доступа к "новому формату" нам нужен?

Амижные дататайпы? Открыть готовый/создать новый(пустой, из шаблона)/сохранить/разобрать (проиндексировать для поиска?) ?

Метаданные для "подписи" файла целиком? Для поиска файла по метаданным (или индексам "по содержимому"?)

Метаданные для "навигации в элементах файла"? Для адресации цитат, абзацев, глав в книге?

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

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

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

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

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

>>в досе используются .три буквы будем считать это ключём(хэшем) к таблице

>Рисширение отнюдь не всегда однозначно указывает на тип файла и примеров тому море. Особенно если учитывать не самые распространённые программы и служебные файлы программ в собственном формате.

Поэтому, должно быть универсальное обозначение типа, вроде mime-types. Организованное в пространство имён, если потребуется.

Хешем/ключём в таблице лучше считать содержимое файла (без заголовка). Прочитай как устроено "объектное хранилище git", +я тут на ЛОРе выдвигал мысли про git-blobs file system http://www.linux.org.ru/view-message.jsp?msgid=2361951&page=4#2364245

(ну и по обратным ссылкам "в ответ на" начиная с http://www.linux.org.ru/jump-message.jsp?msgid=2361951&cid=2367299, или читай весь топик :))

>>+ в базе можно проверять ещё по дополнительным признакам, эврестический поиск по числу символов, их распределению, сплайсу, фрактальному образу, проекции в торсионном поле или множестве чисел C

>Простота методов в действии. Ещё проще - открыть файл hex-вьювером и на глаз определить. Метод тоже весьма действенный но...

не надо "на глаз определять". Надо дать возможность сохранить дополнительные признаки-метаданные и дать унифицированный интерфейс для добавления метаданных, унифицированный интерфейс для адресации по метаданным (вроде трансляторов в ХУРДе: мы можем пометить файл "тегом" и адресовать по своему пространству имён внутри тегов, вроде .../tags/blabla+yadda+yadda@[size<100k] ).

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

>1. куда указывает эта строка, если такой программы в системе нету? (например попала видюха с новым кодеком.)

в том-то и проблема, что она указывает в путь в "локальной ФС", который на каждой системе свой. Например, у одного Perl стоит в /usr/bin/perl , у другого - в /usr/bin/local/perl, у третьего вообще /c:/perl/bin :)

А если в качестве путей брать тот же "хэш по содержимому блоба", уникальный адрес блоба-файла в gitfs, то мы получаем универсально адресуемые(GUID) уникальные сущности. Можно URL взять или HURD-пути вроде /dev/window/GUID_of(..). >2. мне нужно узнать, что там, а не посмотреть кино. Нужно название, саундтрек или титры...

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

>В tiff эту проблему вполне решили. в текстах unicode тоже вроде как. Если я правильно понял, в IFF упоминавшемся ниже - тоже. А хедер загадит - так от намеренной порчи спасай не спасай...

"побайтово читать нельзя" -- значит, не подходит интерфейс open/read/write/close. Ну так дадим ссылку на тот интерфейс, которым читать можно. А ссылка будет GUID на объект, который может храниться в том же самом контейнере и прописываться "в систему", при первом обращении.

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

Например, как реализован распределённый пакетный менеджер 0install:

http://0install.net/walkthrough.html

>TripleGluk (*) (12.01.2008 14:30:14)

идея про УФК интересная, но непонятно -- зачем? :)) в смысле, первым пунктом надо рассказать что это даёт нового, не доступного ранее, цели этой идеи. А то прям получается очередное "патентованное средство от всех болезней"

Второй пост читал, но может это озвучить явно, для наглядности?

Может, эти все идеи засунуть в какую-то вику (есть бесплатные вики-хостинги), или pastebin и там устроить обсуждение?

>6) Преимущества УФК перед тем, что мы имеем (потоки, "рассыпуха", собственные контейнеры).

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

эквивалентность "складывания в папку" и УФК:

/dir/file1.. /dir/fileN =

/proc/upyachka/byPath/dir/file-ufk.ufk/file1 ..

/proc/upyachka/byPath/dir/file-ufk.ufk/fileN

> Всё-таки это только часть задачи.

Озвучь задачу явно.

> Одно другого не исключает. Скорее наоборот - облегчает. Смысл унификации - <..огласите_весь_список..>

согласен с постом, +1, см. выше про эквивалентность.

> А уж через апи или ещё как- это дело вкуса. Хотя при наличии стандарта - апи сделать не проблема.

что мы пытаемся стандартизировать и какой API выработать?

смысл моего поста был в том, чтобы максимально использовать уже имеющийся open/read/write/close, введя только новое уникальное пространство имён, и вызывая программу-обработчик для адресации элементов этого пространства имён. Внешне со стороны приложения остаётся старый добрый open/read/write/close.

Интересно, когда, в каких случаях его будет не хватать :)

> p.s. а потом после контейнера пойдёт, что файл побайтово читать нельзя давайте ему методы защищённые присобачим

даём ссылку на интерфейс, реализация лежит в этом же файле-контейнере или выкачивается из интернета(локалки, другого файла-контейнера, итп)

> (вдруг кто хедер загадит),

не даём в рамках нашего интерфейса доступа писать в хедер, доступен сразу блоб, с отрезанным хедером. Хедер будет присобачивать обёртка нашего интерфейса в legacy-интерфейс вроде open/read/write/close, если он понадобится.

>число в файле хранить нельзя ибо на разной архитектуре, разное число бит для целого,

вставляем проверки, вроде BOM в Unicode, и т.п. В сам блоб или в хедер, смотря какой интерфейс потребуется

>бла-бла-бла получаем xml

получаем интерфейс доступа, который может быть мостом в другие: open/read/write/close, XML, и т. п. Интерфейс должен быть самодостаточный, расширяемый как тот же XML, да. Но если нам не нужен generic XML интерфейс, можем использовать быстрое нужное подAPI, которому не нужно парсить "весь XML целиком", потому что уже распарсено до нас, и априори ясно, в каком вложенном контексте пространства имён мы работаем.

> Судя по всему tar - наиболее близко к изначальной идее.

напрашивается сводная таблица по фичам, преимуществам и недостаткам: tar/dmg/iso/cloop/wad/rar/zip/iff/avi/UberUFK :) Чтобы было ясно, чего ради изобретается велосипед :)

+ vhd , образы дисков Висты, Acronis, итп :)

> отслеживание истории "кусочков" copy/pase, трансклюзия в Xanadu

> Сам файл должен быть "составным", из кусочков

Придумался вдруг такой GUI для организации рабочего пространства: что-то среднее между МакОСью и dwm c тегами: (2 на экране) строка-меню с названием приложения, показывающим "контекст" внимания пользователя, и (1 на экране) строка над ней с облаком тегов, категориями, как в теги "рабочих пространств" в dwm. Ну и еще выше (0 строка :)) можно втулить схему текущего процесса - работы, что-то вроде списка этапов с наглядной демонстрацией "сейчас находимся на таком-то этапе"

Чтобы перед глазами всегда был виден "контекст внимания" пользователя и удобная навигация по "кусочкам", на которые тратит внимание пользователь.

Цель такого GUI: сократить "контекстные переключения" внимания пользователя, чтобы если отвлёкся от компа, было понятно что он делал и где сейчас находится.

Файлов в обычном понимании там не будет, будут "кусочки информации", помеченные тегами, облако тегов, теги, сгруппированные в категории.

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

>>losetup

>Не совсем понял, как это поможет. Можно поподробнее?

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

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

dd if=/dev/cdrom of=/tmp/iso/disk.iso

mount -o loop /tmp/iso/disk.iso /mnt/virtualCD

> На счёт dmg ничего не скажу. Не удалось найти о нём нормальной инфы. Если есть линк - было бы интересно посмотреть.

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

посмотри ещё вот это: http://icculus.org/physfs/