LINUX.ORG.RU

Универсальный(?) формат хранения данных

 , , ,


2

3

Будет много текста.

Я даже не знаю, скорее всего я спрашиваю — «где мне взять такое готовое?», но, дело в том, что кратко я это описать не смогу, т.к. не знаю как это называется.

Итак, что же мне нужно.

Я хочу раз и навсегда выбрать и использовать универсальный формат хранения данных. Что я под этим подразумеваю?

Берем некую абстрактную программу, которая манипулирует какими-либо данными. И эти данные сохраняются. Пусть будут живые примеры: Ardour сохраняет свои проекты в XML, фотошоп в своем бинарном, ёксель в zip+XML, ну и т.д...

Как правило (в приведенных примерах и далее в моем случае) сами данные представляют собой «дерево» где какие-то зависимые элементы лежат внутри родительских. Некоторые (ёксель) комбинируют несколько уровней для создания дерева данных: zip->fs->xml.

А зачем это все? Я же просто хочу сохранять состояние, файл проекта, логи или что-то еще.. Т.е, конечно понятно, возможно где-то удобен xml, где-то JSON, где-то ini, а где-то бинарь. Но проблема в том, что у всех все по разному. И для преобразования в удобоваримый вид внутри приложения (структуры, массивы, указатели, ссылки, значения), (кроме бинарного хранения) необходим парсер и интерпретатор/транслятор этих данных, причем в обе стороны (fs->?*->app и app->?*->fs). Форматов много, и для каждого куча либ, писанных за авторстом от васяна до профессора.

Нет, я пишу сюда потому, что не хочу чтобы случилось так: http://twentysix.ru/uploads/images/00/91/06/2016/05/10/adaaed_full.png

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

Итак, поехали.

1) Формат хранения данных — бинарный. Да, бинарный. Почему? Потому что сразу прочитал его в память (да, с валидацией, о ней ниже) и все.

2) Дерево данных. Каждый узел — это бинарный пакет с заголовком, хешсуммой и указанием размера узла, включая размеры потомков, или смещения откуда начинаются потомки со своими заголовками. Да, декларативное бинарное описание структур данных любого моего/вашего приложения.

3) Единый парсер-транслятор туда/сюда. Он знает только то, как ему распарсить свои декларации, отсеить их, а на выходе будут уже готовые к работе данные в памяти. Таким образом вы можете seek'ать в файле или ожидать желаемую позицию смещения в буфере, чтобы пропустить не интересующие вас в данный момент данные (в XML, да и в любых text-based, с этим облом, он последовательный, текстовый, посимвольный, пока не пропарсишь минимум узел, а он может быть огромным, с вложениями, ты не узнаешь структуру). Так же для парсера должна быть определена схема (отсылка к XSD schema) внутри приложения, можете называть это конфигом парсера для заточки именно под ваши данные. Именно сюда могут быть и «забиндены коллбеки валидатора». При сохранении же должно быть обратное действие.

Теперь снова простыми словами.

Я хочу что-то типа бинарного XML, ака узлы-пакеты, где сразу лежат бинарные данные. И универсально транслировать это все в сишное приложение.

Так вот. Есть ли такое готовое? Если есть — подскажите. Если нет — отпишитесь что вы обо всем этом думаете? Какие слабые и сильные стороны этой эпопеи?

<joke-mode>Хм... Да, очень похоже на кусок OSI. Но почему данные не хранят в виде TCP пакетов?</joke-mode>

Сабж.

★★★★★

Последнее исправление: deep-purple (всего исправлений: 1)

Ответ на: комментарий от shkolnick-kun

А смарт-ТВ?

А IoT-микроволновка?

Расскажи мне об основанных на ASN.1 протоколах, существенных SmartTV и IoT.

Страшно?

Нет. А должно быть?

Но людей, которые возятся с ASN.1, жаль.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

Cap'n'Proto уже называли?

intelfx ★★★★★
()
Ответ на: комментарий от tailgunner

Расскажи мне об основанных на ASN.1 протоколах, существенных SmartTV и IoT.

http://www.rane.com/note161.html

https://tools.ietf.org/html/rfc3779

http://www.oss.com/asn1/resources/standards-use-asn1.html

Нет. А должно быть?

Тебе решать...

А вот гнутая реализация https://www.gnu.org/software/libtasn1/

shkolnick-kun ★★★★★
()
Последнее исправление: shkolnick-kun (всего исправлений: 1)

В качестве бреда — tar?

false ★★★★★
()

Странно, почему еще не посоветовали SQLite?

Deleted
()

Универсальный формат уже существует и всеми используется. Называется «последовательность байт».

Miguel ★★★★★
()

Binary property list

Deleted
()
Ответ на: комментарий от tailgunner

snmp использует asn.1 ber. x.509, а значит и tls, использует asn.1 der. tls нужен везде. snmp тоже никакой iot примочке не помешает.

iliyap ★★★★★
()

Я же просто хочу сохранять состояние

*Делая характерный жест рукой*
- Нет, ты не хочешь сохранять состояние! )
Всё уже сохранено. AS/400 и последыши.

GAMer ★★★★★
()
Ответ на: комментарий от iliyap

snmp использует asn.1 ber. x.509, а значит и tls, использует asn.1 der. tls нужен везде.

Да, Капитан (хотя в TLS оно попало опять же благодаря сумрачному гению ITU). Менее очевидные и более свежие примеры будут?

tailgunner ★★★★★
()
Ответ на: комментарий от deep-purple

ты сначала на практике поработай с тем ASN.1,а потом уже радуйся. на практике это монстрозный и крайне неудобный для работы формат. откуда он взялся - сказать сложно. видимо, от каких-то примитивных аналоговых АТС остался, которые умели только в него. потому что в телекоме он встречается и, пожалуй, больше нигде.

Iron_Bug ★★★★★
()
Ответ на: комментарий от iliyap

snmp уже не в тренде. netconf его вытеснил в современных железках.

Iron_Bug ★★★★★
()
Ответ на: комментарий от deep-purple

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

делая джедайские пассы

не нужен бинарный формат тебе, юный падаван
всех спасут S-выражения
скобкота это сила

познай сторону силы
емакс твой друг

anonymous
()

EBML посмотреть предлагали?

FeyFre ★★★★
()
Ответ на: комментарий от anonymous

ну пишет он на сишечке. так в последнем емаксе уже и в гну можно расширения .so на сишечке писать (в хемаксе это уже лет двадцать).

обработку писать на сишечке модулем, а управление — на елиспе, емаксом. прикрутить EIEIO (недоделанный CLOS для елиспа) и получить персистентные объекты с метаобъектным протоколом.

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

anonymous
()

Имплементируй gob на C и будет что-то похожее на твою хотелки.

PS: про ASN.1 уже вспоминали.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Открою тебе тайну — ASN.1 живее всех живых. ;) Да, к нему надо привыкнуть, но он всё таки с головой сделан... хоть и местами через 5-ю точку.

Где он жив? TLS, SNMP, LDAP, GSM, LTE ... вообще вся телефония и много-много ещё где.

beastie ★★★★★
()
Ответ на: комментарий от anonymous

причём между хешами персистентных структур могут быть гиперссылки... на символы из CLOS-объектов

получаем векторный гипертекстовый фидонет... :-)))

ну или расширение hyperbole для xemacs (где можно было прикрутить гиперссылку кнопкой в свой ~/.xemacs, отправить её емейлом или в GNUS или в erc, и тот кто эту ASCII-графику получил емаксом c теми же настройками, получал гиперссылку кнопкой в емаксе, на которую можно нажать (и пройти по гиперссылке) )

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

там ещё и спредшит какой-то был в hyperbole, то есть, совсем-таки в духе ZigZag и applitudes Теда Нельсона :-)))

anonymous
()
Ответ на: комментарий от anonymous

спасибо, очень занятно

Еще бы иметь карманный elisp/lisp всегда под рукой и удобные возможности по embed-встраиванию в приложения как у питона ...

anonymous
()
Ответ на: комментарий от anonymous

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

например, emact от автора OpenLisp. вместе с OpenLisp-ом.

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

так что свою реализацию ISO ISLISP писать придётся (как язык, он всяко проще ANSI Common Lisp, но мощностью не слабее), и вкорячивать в исходники Emact по аналогии.

anonymous
()
Ответ на: комментарий от beastie

LE был для примера. Я вот смотрю — народ то подписался, значит интересно не мне одному.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

3g, lte, авионика и космонавтика вся юзает per. Дальше читай про csn1, esn или как его там и acn. Xer и прочие ништяки. Признавайся что пернул в лужу дружок. Хотя опенсорс сосет в єтос деле, да.

anonymous
()
Ответ на: комментарий от Iron_Bug

О, спецьі в треде, все в машину

anonymous
()
Ответ на: комментарий от Iron_Bug

И в догонку: вьілазь из своего говна++

anonymous
()
Ответ на: комментарий от anonymous

3g, lte, авионика и космонавтика вся юзает per

3G и LTE - это тот самый ITU. Про «всю авионику и космонавтику» хотелось бы пруфов.

Признавайся что пернул в лужу дружок

Пока что ты.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

3G и LTE - это тот самый ITU.

это никак не опровергает того, что именно ты пернул в лужу.

Про «всю авионику и космонавтику» хотелось бы пруфов.

http://www.itu.int/en/ITU-T/asn1/Pages/Uses/Aviation.aspx драфты стандартов соответствующих организаций найдёшь сам

дальше гугл nasa asn.1 найдёшь кучу пропозалов и статей. И да, ни одна вакансия програмера в airbus например не обходится без пункта asn.1

anonymous
()
Ответ на: комментарий от anonymous

3G и LTE - это тот самый ITU.

это никак не опровергает того

Лан.

tailgunner ★★★★★
()
Ответ на: комментарий от beastie

я и не спорю, что он жив. просто он УГ по своей структуре. что с точки зрения обработки, что с точки зрения передачи данных. УГ иногда не тонет и держится на плаву много десятилетий. что не отменяет его унылости.
я работала в телекоме раньше. именно там я с ним и столкнулась. врагу не пожелаешь такого формата данных. я так понимаю, что держится в телекоме он исключительно по историческим причинам: когда-то он появился из-за примитивного железа, которое могло только так данные формировать. и так и поддерживался много лет, хотя железо сейчас уже давно его не использует, так иногда из железа поток перекодируют сначала в ASN.1, а потом обратно! для совместимости со старыми АТС-ками. сейчас чтобы его выкорчевать, надо там много чего переписать. а никто не хочет заморачиваться. поэтому он до сих пор используется.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

С точки зрения бинарного представления там как раз всё на высоте. Компактный, само-документируемый формат. Для передачи разношёрстных структурированных данных — самое оно.

Беда только, что вменяемых компиляторов для него — раз-два и обчёлся. Из всех языков, IIRC только Erlang его «из-коробки» умеет (происхождение обязывает). Для C — все открытые компиляторы — мягко говоря не дотягивают.

Сейчас, кстати, protobuf ту же нишу занять пытается.

Но ASN.1 будет с нами ещё не одно столетие. Как ты уже заметила, TLS & Co. никто переписывать не спешит. ;)

beastie ★★★★★
()
Ответ на: комментарий от beastie

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

ну, он не в самом TLS. это лишь формат сертификатов.

Таки нет. Все сообщения TLS передаются DER-encoded. Хоть и в rfc5246 оно описано в виде C структур, но на самом деле всё там чистый ASN.1

А сертификаты — это всего лишь маленькая часть протокола. Запусти wireshark, если на слово не веришь. :)

PS: есть правда ещё одна проблема — в свободном доступе грамматики днём с огнём не сыщешь. :(

Вот пару мест, где я их в своё время выкапывал: ecma, globalspec, ... и много google-fu.

PPS: а у мну сейчас много секса с grpc и protobuf :) — в принципе это теже яйца, но причёсанные и в профиль. Типов меньше, всё чуть проще, но ...

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от MKuznetsov

Плюсую asn.1, man asn1parse.

бинарный, дерево есть, хеш/црц сам добавишь.

sergej ★★★★★
()
Ответ на: комментарий от beastie

это не так. я 5246 практически наизусть помню, как и прочие дополнения и обновления к нему, коих довольно много. ASN.1 там только в шифровании самих сертификатов и данных, но не в протоколе TLS. и я это руками парсить умею. я ковыряюсь в TCP-стеке уже не один год.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.