Varlink — интерфейс ядра

который удобен для чтения как людьми, так и машинами.

sexp?

UPD:

JSON
удобен для чтения людьми

ок

В протоколе Varlink все сообщения кодируются как объекты JSON и заканчиваются байтом NUL.

Т.е. нулевой байт по этому протоколу передать не получится?

получится, man unicode

Зато произвольные байты передать не получится, man unicode.

Ну, вернее, получится, если исхитриться и ввести специальную кодировку поверх юникода, кодируемого в ASCII. Мельком видел такое развлечение, когда хотели произвольные ответы веб-сервера пихать в ElasticSearch, но не хотели всё конвертировать в base64, потому что тогда не будет работать поиск. А с трюками и текст ищется, если он в ASCII или UTF-8, и все байты сохраняются точь в точь. Та ещё радость.

Т.е. нулевой байт по этому протоколу передать не получится?

{ "binary": "\x00\x01\xFE\xFF" }

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

Принципиально-то получится - хоть base64, хоть тупой массив из байтов, хоть строка с escape-последовательностями. Эффективность, конечно, будет огорчать.

Тыщу лет всё прогрессивное человечество пользуется IDL, но нет, смузихлёбам надо непременно всё в json завернуть.

Есит сотни классных форматов сериализации. Нахрен всем уперся этот жсон. В этом проекте он уж точно не к месту

https://en.m.wikipedia.org/wiki/Comparison_of_data-serialization_formats

К месту ли там JSON, если данные ведь в основном будут ходить бинарные?

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

# The current state of the FTL drive and the amount of
# fuel available to jump.
type DriveCondition (
  state: (idle, spooling, busy),
  tylium_level: int
)

# The galactic coordinates use the Sun as the origin.
# Galactic longitude is measured with primary direction
# from the Sun to the center of the galaxy in the galactic
# plane, while the galactic latitude measures the angle
# of the object above the galactic plane.
type Coordinate (
  longitude: float,
  latitude: float,
  distance: int
)

# Calculate the drive's jump parameters from the current
# position to the target position in the galaxy
method CalculateConfiguration(
  current: Coordinate,
  target: Coordinate
) -> (configuration: DriveConfiguration)

# Jump to the calculated point in space
method Jump(configuration: DriveConfiguration) -> ()

Примерно то же генерит haddock.

Varlink – это интерфейс ядра и протокол, который удобен для чтения как людьми, так и машинами.

huh?! это в смысле зачем..? чтобы я что, напрямую с ядром мог общаться??? но зачем? пусть с ядром общаются программы, а я буду общаться с программами...

JSON

а ну дда, куда ж без этого...

Нас уже двое.

{ «binary»: «\x00\x01\xFE\xFF» }

и главное, компактно! почти никаких накладных расходов!

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

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

Так у них и свой IDL есть, не руками же в жсон сериализавать/десериализовать

А такое будет через .App работать?

я, пожалуй, за вами займу

Что бы core i9 в минималках хеллоуворлда перестал быть анекдотом.

вот к нему готовый интерфейс.

только «драйвер» к этому интерфейсу похоже еще не написан

Чем оно лучше protobuf? И при чём тут ядро?

Может это такой их ответ на «бинарные логи» ? ;)

Есит сотни классных форматов сериализации.

https://en.m.wikipedia.org/wiki/Comparison_of_data-serialization_formats

Перечислено 35. Из них большая часть — или вариации на тему JSON и XML, или явно не имеют преимуществ перед JSON: YAML, CSV, p-list, OpenDDL, или плохо переносимы с воркэраундом в виде JSON/XML, как pickle.

Что из оставшегося удобнее JSON-а?

больше %уйни богу %уйни! Даешь SOAP в ядре

все сообщения кодируются как объекты JSON

ну это жесть какая-то.

6 абзацев шизофазии
Проверено: Shaman007

Лепота.

Удобнее JSONа практически всё, тот же XML можно хорошо приготовить (но не нужно). Из хороших практичных вариантов это protobuf с текстовым представлением на порядки читабельнее JSON-а. Или более лёгкие вариации TLV (tag-length-value, protbuf одна из его оптимальных форм) на бинарном уровне и аналог prototext-а для пользователя. Топик не нужен, это очередная хипстерская поделка недодизайнера.

умно:)

Toml is a data serialisation language designed to be a minimal configuration file format that's easy to read due to obvious semantics. It is an alternative to YAML and JSON. It aims to be more human friendly than JSON and simpler that YAML. TOML is designed to map unambiguously to a hash table.

ALLO, KDBUS, ETO TI?

Зачем за нами? Присоединяйся, третьим будешь. :)

JSON это конечно стильно, модно, молодежно.

Но объясните виндонубу, зачем это нужно ?)

объясните виндонубу, зачем это нужно? )

Прост)

В таком виде описание этого интерфейса очень напоминает... sh. который также имеется в ядре.

JSON стал одной из самых востребованных фич, добавленных в SQL Server 2016

JSON as a bridge between NoSQL and relational worlds

Вот я тоже думал, что это за х#$я, зашел в репу, а там @kaysievers... ну, короче, все понятно, расходимся. Надеюсь, Линус еще не окончательно стал толерантным и инклюзивным, и прогонит его снова ссаными тряпками.

очередная приблуда для мамкиных веб-погромистов? догадываюсь откуда JSON (javascript) взялся.

догадываюсь откуда JSON (javascript) взялся.

Зачем догадываться, если я прямо написал: чтобы результаты класть в ElasticSearch. Возможно, он в каком-то другом виде умеет данные принимать, хранить и обрабатывать, но я не в курсе. Знаю, что он принимает POST-запросы с полезной нагрузкой в виде JSON. Мне говорили, что ему становится плохо, если JSON невалидный. А валидный JSON — в UTF-8.

Удобнее JSONа практически всё, тот же XML

А ты, затейливый!

Toml

Авторы несогласны :)

https://github.com/toml-lang/toml :

TOML ... is not intended for serializing arbitrary data structures
it doesn't permit top-level arrays or floats, so it cannot directly serialize some data.
There is also no standard identifying the start or end of a TOML file

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

Сколько я с ним работал — для статических конфигов не лучше и не хуже, чем JSON или YAML. Только парсер на Го подглючивает, не всегда читает конфиг до конца.

Удобнее JSONа практически всё, тот же XML можно хорошо приготовить (но не нужно).

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

protobuf с текстовым представлением
лёгкие вариации TLV ... и аналог prototext-а для пользователя.

Смотрю. Сериализация protobuf в человекочитаемые помимо XML есть?

ini файлы даже удобнее чем json

удобнее для чего? как ты померил удобство?

Что это за хрень, интерфейс ведра для чего?

пусть с ядром общаются программы, а я буду общаться с программами...

А ты типа не программа? Ну ок, давай как будто мы поверили

Стабильность!даже такая,плохая стабильность.

Как насчёт бинарных форматов? Которые и занимают меньше места при пересылке, и кодируются/раскодируются быстрее? И в которых тебе не обязательно раскодировать всё сообщение, чтобы получить только его часть?

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

У папуасов в треде тоже зачётно подгорает, однако.