Libelektra: Библиотека для типов

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

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

@ bauhaus93, если вы не видите немедленной выгоды от наличия библиотеки типов (например, повторного использования с другим плагином), закройте проблему.

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

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

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

Но я пометил это как low priority именно потому, что я знал, что это много работы и, вероятно, никто не хочет этим заниматься.

Что касается типов, я не уверен в возможности повторного использования, за исключением, может быть, проверки / преобразования недесятичных целых чисел (двоичных / восьмеричных / шестнадцатеричных) или даты (TOML использует дату и время RFC 3339).
Не связанные с типами, я вижу некоторую возможность повторного использования при подготовке KeySets для написания (например, функции, которые обновляют / добавляют array metakeys, удаляют array metakeys недопустимых массивов или полностью отсутствуют comment/#X метакейданные).

Возможно, вы этого еще не заметили, но также могут быть проблемы с нормализацией логических значений, которые выполняет плагин типа. Это, вероятно, наиболее часто используемый код, поскольку в большинстве форматов используется true / false а в Elektra используется 1 / 0 . Я думаю, что yamlcpp пришлось добавить специальный код, чтобы логические значения не преобразовывались в целые числа или наоборот (или что-то в этом роде).

Ах да, забыл об этом, плагин TOML тоже должен нормализовать эти значения.

Проблема не только в том, что вам нужно нормализовать значения. Вы также должны точно знать , что type плагин делает, так как он работает до toml плагин в kdbSet фазе. Я не уверен, реализовали ли мы это когда-либо, но вы также должны убедиться, что плагин type генерирует только 1 / 0 или true / false в фазе kdbSet , независимо от конфигурации, предоставленной пользователем. В противном случае toml должен иметь возможность анализировать конфигурацию плагина type , поскольку пользователь может устанавливать собственные значения true и false (см. Тестовый пример ниже)

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L734 -L771

Интересная часть:

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L749 -L753

Плагин type получает 1 в kdbGet (может быть от toml ), но возвращает t в kdbSet . Это может доходить до того, что пользователь определит true = 0 и false = 1 что полностью запутает плагин toml . (Я думаю, что все логические значения будут переворачиваться каждые kdbSet )

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

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

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

Большинство пользователей, вероятно, хотят написать только грамматику, а все остальное должно произойти само собой. Интересно, как далеко плагин TOML от @ bauhaus93 на самом деле достиг этой цели. Было бы интересно сделать плагин не-TOML с кодовой базой плагина TOML. Однако сама по себе библиотека типов кажется мне слишком специализированной, чтобы быть слишком полезной для большой задачи «написания подключаемого модуля хранения».

Что касается типов, я не уверен в возможности повторного использования, за исключением, может быть, проверки / преобразования недесятичных целых чисел (двоичных / восьмеричных / шестнадцатеричных) или даты (TOML использует дату и время RFC 3339).

Дата / время существовали в Elektra только для проверки, но там поддерживался только RFC2822. Плагин даты может повторно использовать ваш синтаксический анализатор для проверки RFC 3339, но я считаю это очень низким приоритетом.

Что было бы немного интереснее, так это что-то вроде keyGetDateTime(Key *k, struct tm *tm) из ключа с датой (TOML).

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

Да, это может быть интересно. Но еще более увлекательной была бы возможность как можно меньше напрямую изменять грамматику и сенсорный код: wink:

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

Чего не хватает, так это некоторого руководства / объяснения в doc / tutorials / storage-plugins.md, которое дает актуальное представление о том, на какие плагины должен полагаться плагин хранилища. # 2330 покажет, может ли "двоичный" быть нужен и по-прежнему ли он подходит в качестве хранилища по умолчанию.

Вы также должны точно знать, что делает плагин типа, поскольку он запускается перед плагином toml на этапе kdbSet.

Вероятно, плагины хранения должны перестать использовать плагин типа и просто самостоятельно выполнять свою нормализацию (от истинного / ложного в их формате до 1/0 в Elektra и т. Д.). @ bauhaus93, какие еще функции плагина типа вы используете?

Это может зайти так далеко, что пользователь определит, что true = 0 и false = 1, что полностью запутает плагин toml.

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

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

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

Большинство пользователей, вероятно, хотят написать только грамматику, а все остальное должно произойти само собой.

Это кажется слишком волшебным, чтобы быть возможным. Это возможно с помощью специального генератора кода, основанного на модифицированной грамматике Yacc или ANTLR. Но я не думаю, что есть способ создать код, который создает KeySet s просто из грамматики для совершенно разных форматов, таких как JSON, XML, TOML и edn . Как обнаружил @ 'sanssecours, там также были такие форматы, как YAML, которые очень трудно выразить в стандартном грамматическом формате.

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

Конечно, мы могли бы расширить библиотеку до общей библиотеки storage которая предоставляет больше вспомогательных функций для плагинов хранения (например, работа с stdin / stdout и конвейерами для импорта / экспорта). Тогда типовой материал будет частью этого.

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

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

Что было бы немного интереснее, так это что-то вроде keyGetDateTime (Key * k, struct tm * tm)

Похоже на работу по преобразованию части libease (как elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@ bauhaus93 функции могут быть полезны и для toml . Они спроектированы таким образом, что, например, elektraKeyToFloat и elektraFloatToString совершают совершенный и без потерь двусторонний (независимо от того, начинаете ли вы с числа с плавающей точкой в ​​строке), и они также используются в высокоуровневом API. Итак, если toml создает ключ с помощью elektra*ToString он определенно может быть правильно прочитан высокоуровневым API, а toml определенно может правильно прочитать все, что highlevel API, созданное с помощью elektraKeyTo* .

актуальное представление о том, на какие плагины должен полагаться плагин хранилища.

ИМО, подключаемый модуль хранилища никогда не должен _ полагаться_ на какой-либо другой подключаемый модуль. Плагины хранилища могут быть расширены другими плагинами, но в идеале они должны работать автономно.

Даже работу с двоичными ключами лучше решить с помощью библиотеки хранения / типов. Опять же, он гарантирует некоторый базовый стандарт для сообщений об ошибках и т. Д. Он также избегает использования плагина binary для форматов, которые в нем не нуждаются. Хотя binary сочетании, например, с quickdump будет работать, это плохо как для скорости, так и для размера хранилища.

Вероятно, плагины хранилища должны перестать использовать плагин типа и просто сами выполнять свою нормализацию.

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

Я был бы за сокращение функциональности плагина типа.

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

Во всяком случае, некоторые дополнительные значения истина / ложь должны определяться пользователем (которые, очевидно, раньше не были значениями истина / ложь).

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

Даже true = 0 и false = 1 вполне подойдут. Сама компания Elektra штрафует логические значения, поскольку « 1 - единственное истинное значение, а 0 - единственное ложное значение».

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

Я не согласен. Составить исчерпывающий список, конечно, невозможно (в конце концов, существуют и сторонние плагины), но решение простое. Пусть плагины сделают проверку сами. Либо в elektra<Plugin>Get или в другой функции, вызываемой во время kdb mount .

Помимо логического, плагин TOML также устанавливает при чтении типы string, double и (unsigned_) long_long.

Я согласен с @kodebach , что плагин type должен использоваться только плагинами без встроенной системы типов из-за трудностей во взаимодействии.
Например. плагин TOML устанавливает метакей type для целых чисел при чтении также и для недесятичных значений (при преобразовании его в десятичное, сохранение недесятичного представления в origvalue ). Однако, если вы хотите изменить такое типизированное значение с помощью kdb set (и сделать это с помощью двоичного / восьмеричного / шестнадцатеричного значения), вы не сможете сделать это напрямую (установив значение ключа), потому что type Проверка типа плагина не будет успешной. Вместо этого вам придется изменить метакей origvalue . (Удаление метакея type перед установкой нового значения не сработает, так как метакейка будет повторно установлена ​​при чтении.)

Проблема не только в том, что вам нужно нормализовать значения. Вы также должны точно знать, что делает плагин типа, поскольку он запускается перед плагином toml на этапе kdbSet. Я не уверен, реализовали ли мы это когда-либо, но вы также должны убедиться, что плагин типа выдает только 1/0 или true / false на этапе kdbSet, независимо от конфигурации, предоставленной пользователем. В противном случае toml должен был бы иметь возможность анализировать конфигурацию плагина типа, поскольку пользователь может устанавливать собственные значения true и false (см. Тестовый пример ниже)

Да, я уже задавался вопросом, могу ли / как я на самом деле проверить определенные пользователем логические значения. В настоящее время при написании плагин TOML рассматривает только значения "1" и "true" как истинные, остальные будут рассматриваться как ложные.

@kodebach написал:

Это кажется слишком волшебным, чтобы быть возможным.

С Авгием это возможно (но деревья, которые вы получите, не так желательны). Было бы интересно, насколько мы далеки от текущего решения TOML. Конечно, вам нужно написать код эмиттера, но обычно это не так драматично.

JSON, XML

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

Но, конечно, первое и самое главное - получить хороший плагин TOML: 1st_place_medal:

Другая стандартная библиотека типов также гарантирует стандартные сообщения об ошибках для проблем с типом.

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

Похоже на работу по преобразованию части libease

Да, вероятно, что-то из TOML может перейти на libease или libmeta.

ИМО, плагин хранилища никогда не должен полагаться на какой-либо другой плагин.

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

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

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

Зачем убирать уже реализованный функционал?

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

К сожалению, даже код, разделенный в плагинах, создает проблемы: например, на сервере сборки или когда пользователь пытается его использовать, возникают нежелательные взаимодействия / отсутствует документ / ...

Мы не можем выпустить все, что у нас сейчас есть, как 1.0, тогда Elektra будет разочарованием. Нам нужно избавиться от всего лишнего. Мы ценим каждую очистку, которую вы можете сделать.

Это также причина, по которой TOML заменит INI. # 3491

Пусть плагины сделают проверку сами.

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

@ bauhaus93 написал:

Помимо логического, плагин TOML также устанавливает при чтении типы string, double и (unsigned_) long_long.

Но это все само по себе без плагина типа? Для чего используется плагин типа?

Вместо этого вам придется изменить исходное значение метакея.

Да, здесь пока нет красивого решения (№3056). keySetString удаляет исходное значение, но почему-то поведение все еще не такое, как ожидал пользователь.

В настоящее время при написании плагин TOML считает истинными только значения «1» и «истина», остальные будут рассматриваться как ложные.

Наверное, надо быть строже и терпеть неудачу во всем, кроме «0» или «1». В самом файле TOML вы также разрешаете только «истина» и «ложь» и ничего больше?

Но это все само по себе без плагина типа? Для чего используется плагин типа?

Да, он делает это сам по себе, разные типы будут сопоставлены во время лексирования. Тем не менее, он не проверяет, переполнены ли десятичные / двойные значения, переполнены ли они long_long / double , поэтому я думаю, что это выполняется плагином type .

Наверное, надо быть строже и терпеть неудачу во всем, кроме «0» или «1». В самом файле TOML вы также разрешаете только «истина» и «ложь» и ничего больше?

Да, я могу сделать это более строгим. В самом файле только true или false записываются / читаются как логические.

по всем остальным функциям это тоже мой вывод.

В этом случае нам понадобится библиотека type . В противном случае любой плагин хранения для формата с типами переопределил бы материал типа (поскольку полагаться на другой плагин не может быть и речи).

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

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

Такой код уже где-то существует?

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

Но это все само по себе без плагина типа? Для чего используется плагин типа?

Да, он делает это сам по себе, разные типы будут сопоставлены во время лексирования. Тем не менее, он не проверяет, переполнены ли десятичные / двойные значения переполнением / недостатком long_long / double , поэтому я думаю, что это выполняется плагином type .

Да, type также выполняет проверку диапазона, проверяет float / double и некоторые другие вещи, например enum s.

Наверное, надо быть строже и терпеть неудачу во всем, кроме «0» или «1». В самом файле TOML вы также разрешаете только «истина» и «ложь» и ничего больше?

И это как раз один из этих чрезвычайно сложных и сложных случаев для типов или, более конкретно, преобразования / нормализации.

Предположим, toml принимает только true / false качестве входных данных и производит только 0 / 1 в kdbGet и это принимает только 0 / 1 и производит только true / false в kdbSet . Это будет соответствовать как спецификации Elektra, так и спецификации TOML для логических значений. Но пользователь, вероятно, ожидал бы, что kdb set /some/key/mounted/with/toml true будет работать. Однако это не так. При правильной конфигурации для type это может работать, но быстро становится неудобным. Например, что, если ключ действительно существовал раньше. Тогда нет метакея type плагин type просто игнорирует его, toml получает true и жалуется, что true недействителен. логическое ...

Это просто показывает, что подключаемый модуль хранилища ДОЛЖЕН иметь возможность обрабатывать все типы, которые поддерживает формат хранилища, и связанные с ними преобразования БЕЗ использования каких-либо других подключаемых модулей.

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

Это справедливый момент, хотя я не думаю, что простое удаление кода - правильное решение. По крайней мере, когда дело доходит до плагинов. В рамках ядра я согласен, чем меньше LOC, тем лучше. Что касается плагинов, мы можем легко сказать, что плагин или его часть являются экспериментальными.

ИМО, плагин хранилища никогда не должен полагаться на какой-либо другой плагин.

Однако этот вывод еще не получил широкого признания (@sanssecours?) И не задокументирован.

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

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

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

Что касается опасения @ markus2330 , что разработка библиотеки общего назначения сложнее, чем аналогичный плагин: это фактически неверно, потому что вы могли бы просто предоставить слегка измененную версию текущей функции elektraTypeGet в качестве библиотеки. Изменения необходимы только потому, что нам нужно заменить Plugin * handle на KeySet * config . Хотя это может не решить всех проблем, но, по крайней мере, позволяет плагину хранилища точно контролировать, как и когда выполняется ввод текста.

Например, toml может иметь резервный режим INI, в котором он не использует систему типов TOML, а вместо этого переключается на type и нормальный режим TOML, в котором он предоставляет elektraTypeGet с очень точной конфигурацией, которая гарантирует, что все соответствует спецификации TOML.

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

Требование, чтобы плагин хранилища заботился о преобразовании типов, ключах каталогов и двоичных данных (кодировка Base64), не упрощает эту работу.

Давайте разберемся с этим:

• Двоичные данные: на самом деле не требуется никаких усилий, чтобы сделать что-то вроде:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  Отдельный плагин также будет работать, если плагин хранилища может обеспечить установку другого плагина при любых обстоятельствах и может просто предполагать, что двоичных ключей нет. Если плагин по-прежнему должен вызвать keyIsBinary и выдать ошибку, это решение не дает никаких преимуществ. Мне также не нравится, что отдельный бинарный плагин должен преобразовывать сразу все KeySet , потому что тогда все ключи Base64 тратят довольно много памяти.
• Ключи каталога: во-первых, эти нелистовые ключи со значениями являются странными почти во всех обстоятельствах, и мы действительно должны рекомендовать избегать их. Когда дело доходит до работы с этими ключами, как указано в # 3256, я думаю, что для этого случая гораздо лучше подходит библиотека. Есть много причин, включая накладные расходы на память и обработку, излишнее усложнение конфигураций точек монтирования и гибкость. Кажется, @ markus2330 (в некоторой степени) согласен со мной в этом вопросе.
• Типы: любой подключаемый модуль хранения для формата, имеющего собственную систему типов, должен будет выполнять по крайней мере некоторую работу с типами. Это может быть как полное преобразование с нуля, вызов какой-то библиотеки, так и настройка другого плагина. Никогда не будет возможно, чтобы все просто работало. Даже если у вас есть очень подробная формальная спецификация типов, так что прямая конфигурация плагина типа не требуется, плагин хранилища должен будет реализовать эту спецификацию тем или иным образом.

Однако он не проверяет, не переполняются ли десятичные / двойные значения или нет long_long / double, поэтому я думаю, что это делается с помощью typeplugin.

Хорошо, так что вы в основном используете его только для проверки.

Но в этом случае отдельный плагин тоже не является решением.

Нет, отдельные плагины, к сожалению, не являются решением. Мы там потерпели неудачу. Текущее решение состоит в том, что каждый плагин хранилища реализует все (кроме обработки двоичных файлов) на основе doc / tutorials / storage-plugins.md.

Но пользователь, вероятно, ожидал бы, что kdb set / some / key / mount / with / toml true будет работать.

Нет, пользователю этого не следует ожидать. В Электре 1/0 верны / ложны. Только плагины хранилища могут сопоставить это с чем-то другим.

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

Это просто показывает, что подключаемый модуль хранилища ДОЛЖЕН иметь возможность обрабатывать все типы, которые поддерживает формат хранилища, и связанные с ними преобразования БЕЗ использования каких-либо других подключаемых модулей.

Да, я согласен.

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

Конечно, нам нужно удалить «правильный» код: тот, который оправдывает ваши ожидания, но не оправдывает их и не вызывает проблем с другими частями Elektra. И некоторые функции плагина типа, кажется, создают проблемы вместе с другими частями Elektra.

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

К сожалению, это не работает (пока *). Люди не оценивают статус плагинов правильно, например, недавно см. # 3472, где считалось, что неподдерживаемый и исправленный ошибками плагин INI и, что еще хуже, устаревший плагин xmltool работает идеально.

• Возможно, будет лучше, если я переделаю # 666, и мы будем выводить предупреждения во время монтажа.

Требование, чтобы плагин хранилища заботился о преобразовании типов, ключах каталогов и двоичных данных (кодировка Base64), не упрощает эту работу.

@sanssecours, как плагины YAML обрабатывают преобразование типов?

Это на самом деле неверно

Посмотрим, когда это будет сделано: stuck_out_tongue_winking_eye:

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

Об этом никто не спорил. Но иногда за гибкость приходится платить.

На самом деле не требуется никаких усилий, чтобы сделать что-то вроде

base64 - не единственный способ кодирования двоичных данных. Для стандартов, где требуется base64, его можно жестко запрограммировать. ( @sanssecours Это случай с YAML?)

Однако для TOML он просто говорит «Base64 или другая подходящая кодировка ASCII или UTF-8», поэтому можно использовать другие двоичные плагины. Таким образом, текущее решение имеет преимущества, так как пользователи могут монтировать другие бинарные плагины по желанию или необходимости.

@ bauhaus93 - infos/needs = base64 следует заменить на - infos/needs = binary .

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

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

[Справочные ключи] Кажется, @ markus2330 (в некоторой степени) согласен со мной в этом вопросе.

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

Хорошо, так что вы в основном используете его только для проверки.

Я не согласен с фразой «плагин toml использует плагин type ». В текущей версии рекомендуется только type .

https://github.com/ElektraInitiative/libelektra/blob/c61e388c4aa950cf84aa2f00fba7cdd34a47640e/src/plugins/toml/README.md#L5 -L6

Даже если type был объявлен как needs , я бы не назвал это "использованием". toml самом деле не имеет прямого контроля над type . Вот почему я сказал, что toml полагается на type . Ожидается, что type делать определенные вещи определенным образом, но я ничего не могу сделать, если это не так.

Возможно, будет лучше, если я переделаю # 666, и мы будем выводить предупреждения во время монтажа.

Я согласен. Возможно, даже на каждые kdbGet , если не был установлен специальный ключ «Я подтверждаю, что эта точка монтирования использует экспериментальные плагины».

base64 - не единственный способ кодирования двоичных данных.

На самом деле это аргумент для плагина binary . Хотя мне по-прежнему нужен интерфейс, через который плагин может работать с одним ключом за раз, это может привести к некоторой экономии памяти и, возможно, производительности. (Но это другая проблема)

Есть очень распространенные во многих форматах.

У вас есть пример?

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

Верно, но в этом случае я бы порекомендовал решение «либо - либо» (с точки зрения конечного пользователя). Либо вы используете старый ключ с единственным значением, либо новую версию с подключами. В противном случае конфигурация, вероятно, запутается.

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

но не с плагином "directoryvalue", так как экранирование не работает

В # 3256 я предложил использовать метаданные для решения проблем с побегом. Также есть мои идеи из # 3223, которые решат проблему с экранированием (для каждого варианта использования, а не только directoryvalue ), а также некоторые другие вещи. См. Также (очень формальное) предложение . Сегодня или завтра я добавлю к этому документу пояснения на простом английском языке, так как я все еще очень поддерживаю эти изменения.

@sanssecours, как плагины YAML обрабатывают преобразование типов?

Yan LR и YAML CPP используют плагин type для логических значений. YAML CPP также использует плагин base64 для двоичных данных.

base64 - не единственный способ кодирования двоичных данных. Для стандартов, где требуется base64, его можно жестко запрограммировать. ( @sanssecours Это случай с YAML?)

Да, насколько мне известно, двоичные данные в YAML всегда используют кодировку Base64.

[нелистовые ключи со значениями] У вас есть пример?

XML и большинство диалектов INI (поскольку они позволяют key=value даже если [key] существует)

Верно, но в этом случае я бы порекомендовал решение «либо - либо» (с точки зрения конечного пользователя). Либо вы используете старый ключ с единственным значением, либо новую версию с подключами. В противном случае конфигурация, вероятно, запутается.

Да, звучит разумно. Как только вы знаете, что что-то является разделом, вы обычно перемещаете значение где-нибудь внутри раздела.

Например, deluser.conf имеет BACKUP = 0 и BACKUP_TO = "." . С разделами большинство приложений будет использовать BACKUP_ENABLE вместо простого BACKUP .

Также есть мои идеи из # 3223, которые решат проблему экранирования (для каждого варианта использования, а не только directoryvalue ), а также некоторые другие вещи.

Я обновил предложение в № 3223. Надеюсь, теперь это легче понять (это еще очень долго).

https://github.com/kodebach/libelektra/blob/dcec6e865bba32f6d83c40c2f711c2e70dde6d62/doc/proposals/keynames.md

Большой вопрос, кто все это будет реализовывать. Это довольно далеко от статус-кво, т. Е. Много работы (одно лишь изменение терминологии - это огромный объем работы). Если вы хотите реализовать это, вы можете создать PR с предложением, и я его прокомментирую. В противном случае нам следует сделать шаг назад и подумать о возможных решениях, которые нам доступны.

Кстати. первая часть предложения на самом деле представляет собой прекрасное руководство о том, как работают имена ключей. Было бы здорово иметь это в качестве учебного пособия. : sparkling_heart:

Большой вопрос, кто все это будет реализовывать.

Это всегда вопрос ...

Это довольно далеко от статус-кво, т. Е. Много работы (одно лишь изменение терминологии - это огромный объем работы).

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

Если вы хотите реализовать это, вы можете создать PR с предложением, и я его прокомментирую. В противном случае нам следует сделать шаг назад и подумать о возможных решениях, которые нам доступны.

Начну пиар, но успею ли я его (в одиночку) закончить в обозримом будущем, сказать не могу.
У меня уже есть локальная ветка, в которой все вызовы keyBaseName , keySetBaseName и keyAddBaseName были заменены на keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart и keyAddUnescapedPart / keyAddLiteralPart . Я создал это с помощью полуавтоматической замены регулярного выражения после того, как написал первое предложение.

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

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

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

Вот почему я написал это так. Я планировал повторно использовать части этого предложения для документации в № 3447. Я не могу использовать его 1: 1, потому что я исключил некоторые очень важные части (например, канонические и неканонические).

Мне нужно говорить откровенно и не давать вам ложных надежд: как вы видели в LCDproc, не бывает, чтобы другие спешили выполнять задачи, особенно когда они утомительны. PR, который уничтожает все плагины хранилища, кроме одного, не может быть объединен. И плагины хранения не получают особой выгоды от этого PR, фактически они становятся «хуже» в том смысле, что они внезапно вызывают синтаксические ошибки в файлах, которые они могли бы проанализировать сейчас. Это не значит, что это плохая идея. С некоторыми уточнениями это может быть лучше, чем статус-кво, но я просто не понимаю, как мы можем справиться с такой большой задачей с таким количеством других неотложных важных открытых задач, которые у нас есть прямо сейчас.

Итак, позвольте нам сосредоточиться на # 3447 (документ), наконец, на # 2969, улучшении плагина TOML и других важных темах, которые нам нужны для 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 и https: // github.com/ElektraInitiative/libelektra/milestone/14). Как только это будет хорошо выглядеть, мы сможем увидеть, какие еще идеи мы сможем реализовать.

Для меня вывод из этого обсуждения состоит в том, что определенно существует потребность в библиотеках, чтобы упростить написание плагинов для хранения, поскольку плагин-подход не работал (за исключением двоичного кода). Этот вывод должен быть в руководстве по плагину хранилища.
@ bauhaus93, можете ли вы продолжить обучение по плагину хранилища? Теперь вы многое понимаете, чего нельзя увидеть, взглянув на исходный код плагина toml.

PR, который уничтожает все плагины хранилища, кроме одного, не может быть объединен.

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

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

Так быть не должно. В конце предложения есть даже частичное объяснение. AFAIK не должно быть случай, когда модуль хранения должен отклонить файл, поскольку он не может быть переведен в KeySet .

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

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

Я никогда не ожидал, что это предложение будет принято немедленно. Но я думаю, что нам обязательно стоит подумать о внедрении его до 1.0. Как только выйдет 1.0, предложение будет огромным изменением. Я не думаю, что выпуск версии 2.0 даже через 1 или 2 года после 1.0 (не говоря уже о более раннем) был бы хорошей идеей, учитывая целевую аудиторию Elektra.

Итак, позвольте нам сконцентрироваться на # 3447 (документ), наконец, на # 2969, улучшении плагина TOML и других важных темах, которые нам нужны для 1.0.

Я абсолютно согласен. Но опять же, мы все равно должны это учитывать, потому что после выпуска 1.0 добавление критических изменений будет очень трудным в течение некоторого времени.

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

👍

за исключением двоичного файла, который нужно увидеть

ИМО, случай двоичных значений совсем другой. Это перевод ключевого значения 1: 1, как и многие другие ( rgbcolor , macaddr , ipaddr и т. Д.), Поэтому плагин здесь действительно хорошо подходит. Однако, как я уже сказал, новый API плагина, который работает только с одним ключом, может быть улучшением. Но это можно легко добавить после версии 1.0, так как это не будет критическим изменением, если все сделано правильно.

большинство -> должны?

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