Libelektra: 类型库

我认为这应该是基于提案形成图书馆的特殊方式。 提取插件之间的通用功能并从中制作一个库更有意义。 @bauhaus93的 TOML 插件包含大量代码，可以将其放入库中（例如注释处理代码）。

不要误会我的意思，这是对@bauhaus93 的很好的输入。 如果有第二个插件需要相同的功能，我们绝对应该把它放到一个库中。 但是制作库比拥有特定于插件的代码要努力得多，而且只有在实际上至少有两个客户的情况下才应该这样做。

@bauhaus93如果您没有看到拥有类型库的直接好处（例如，与另一个插件重用），请关闭该问题。

如果有第二个插件需要相同的功能，我们绝对应该把它放到一个库中

只要第二个插件的开发人员知道在哪里可以找到第一个插件以及如何从那里提取代码而不破坏一切，这是一个很好的策略。 可悲的是，情况往往并非如此。 特别是，因为通常第一个插件必须进行广泛的更改才能使用库。

拥有该库实际上可能会鼓励某人编写新的存储插件，因为一些工作已经完成。

但我将其标记为low priority ，正是因为我知道它需要大量工作，而且可能没有人愿意这样做。

对于类型，我不确定可重用性，除了非十进制整数（二进制/八进制/十六进制）或日期时间（TOML 使用 RFC 3339 日期时间）的验证/转换。
与类型无关，我在准备要编写的 KeySet 时看到了一些可重用性（例如，更新/添加array键、删除无效数组的array键或完全丢失comment/#X函数

您可能还没有注意到它，但是类型插件所做的布尔值规范化也可能存在问题。 这可能是最重用的代码，因为大多数格式将使用true / false但 Elektra 使用1 / 0 。 我认为yamlcpp必须添加一些特殊代码，以便布尔值不会被转换为整数，反之亦然（或类似的东西）。

啊，是的，忘记了，TOML 插件也必须规范化这些值。

问题不仅在于您必须对这些值进行标准化。 您还必须确切地知道type插件的作用，因为它在kdbSet阶段的toml插件之前运行。 我不确定，如果我们实现了它，但你也应该确保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插件在kdbGet （可能来自toml ）中收到1 ，但在kdbSet返回t kdbSet . 这可能会导致用户定义true = 0和false = 1 ，这会完全混淆toml插件。 （我认为所有布尔值都会在每个kdbSet上翻转）

这种极其复杂的交互就是为什么我认为type插件应该用于没有类型的存储格式，而那些有类型的应该明确禁止使用type 。 但是为了实现这一点，我们需要一种简单的方法来支持存储插件中的类型，即类型库。

由于toml插件也处理十六进制数，它可能也应该明确禁止使用hexnumber插件。 （尽管在这种情况下，我认为出现问题的可能性较小）

拥有该库实际上可能会鼓励某人编写新的存储插件，因为一些工作已经完成。

大多数用户可能只想编写语法，其余的应该自己神奇地发生。 我想知道@bauhaus93的 TOML 插件实际上在

对于类型，我不确定可重用性，除了非十进制整数（二进制/八进制/十六进制）或日期时间（TOML 使用 RFC 3339 日期时间）的验证/转换。

Elektra 中存在的日期/时间仅用于验证，但仅支持 RFC2822。 日期插件可以重用您的解析器来验证 RFC 3339，但我认为这是非常低的优先级。

更令人兴奋的是像keyGetDateTime(Key *k, struct tm *tm)来自带有（TOML）日期的密钥。

与类型无关，我在准备要编写的 KeySet 时看到了一些可重用性（例如，更新/添加数组元键的函数，删除无效数组的数组元键或完成丢失的注释/#X 元键数据）。

是的，那可能很有趣。 但更令人着迷的是直接修改语法和尽可能少地接触代码的可能性:wink:

您可能还没有注意到它，但是类型插件所做的布尔值规范化也可能存在问题。

缺少的是 doc/tutorials/storage-plugins.md 中的一些教程/解释，它提供了存储插件实际上应该依赖哪些插件的最新视图。 #2330 将显示是否需要“二进制”并且仍然适合作为默认存储。

您还必须确切地知道类型插件的作用，因为它在 kdbSet 阶段的 toml 插件之前运行。

可能，存储插件应该停止使用类型插件并简单地自己进行规范化（从格式中的任何真/假到 Elektra 中的 1/0 等等）。 @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 toml创建密钥，高级 API 肯定可以正确读取它，而toml肯定可以正确读取highlevel API 生成的任何内容elektraKeyTo* 。

存储插件实际应该依赖哪些插件的最新视图。

IMO，存储插件不应该_依赖_任何其他插件。 存储插件可以由其他插件增强，但理想情况下它们应该独立工作。

即使处理二进制键，存储/类型库也能更好地解决。 它再次保证了错误消息等的一些基线标准。它还避免使用binary插件来处理不需要它的格式。 虽然binary与例如quickdump可以工作，但它对速度和存储大小都不利。

可能，存储插件应该停止使用类型插件并简单地自己进行规范化

这就是为什么我提出了一个图书馆。 提供一个可以完成工作的库比仅仅给出插件必须做什么的非正式描述（甚至正式规范）要好得多。 特别是，如果规范可能会随着时间的推移而改变。

我会赞成减少类型插件的功能。

为什么要取消已经实现的功能？ 最初，这个想法是有一个单独的boolean插件，但这也导致了问题，因为插件排序之类的事情。

如果有的话，用户应该可以定义一些额外的真/假值（显然以前不是真/假值）。

真的没有必要这样做。 只有一个问题，如果多个插件定义了布尔值是什么。

甚至true = 0和false = 1也完全没问题。 Elektra 本身对布尔值进行了罚款，因为“ 1是唯一的真值，而0是唯一的假值”。

没有办法表达插件不能一起工作（拥有这样的功能会使挂载变得更加复杂。维护一个插件与哪个插件一起工作的表格对我们来说也太费力了。）。

我不同意。 详尽的列表当然是不可能的（毕竟还有 3rd 方插件），但解决方案很简单。 让插件自己做检查。 在elektra<Plugin>Get或在kdb mount期间调用的另一个函数中。

除了布尔值，TOML 插件还在读取时设置 string、double 和 (unsigned_)long_long 类型。

我同意@kodebach 的观点，即type插件只能由没有内置类型系统的插件使用，因为交互困难。
例如。 TOML 插件在读取非十进制值时为整数设置type （同时将其转换为十进制，将非十进制表示存储在origvalue ）。 但是，如果您想用kdb set （并通过二进制/八进制/十六进制值）更改此类键入值，则不能直接（通过设置键值）这样做，因为type插件类型检查不会成功。 您必须改为更改origvalue 。 （在设置新值之前删除type将不起作用，因为元键将在读取时重新设置。）

问题不仅在于您必须对这些值进行标准化。 您还必须确切地知道类型插件的作用，因为它在 kdbSet 阶段的 toml 插件之前运行。 我不确定，如果我们曾经实现过它，但您还应该确保类型插件只在 kdbSet 阶段产生 1/0 或 true/false，而不管用户提供的配置如何。 否则 toml 必须能够解析类型插件配置，因为用户可以设置自定义 true 和 false 值（请参阅下面的测试用例）

是的，我已经想知道，是否/如何实际检查用户定义的布尔值。 目前，在编写时，TOML 插件仅将"1"和"true"视为真，其余的将被视为假。

@kodebach写道：

这似乎有点太神奇了，不可能。

使用 Augeas 是可能的（但是你得到的树并不是那么理想）。 有趣的是，我们与当前的 TOML 解决方案相去甚远。 当然，您需要编写一些发射器代码，但这通常不会那么引人注目。

JSON、XML

Elektra 的优势在于，可以用不同的技术实现如此迥异的格式。 尝试从头开始实现 XML 可能不是最好的主意。 如果可以覆盖类似 INI 的格式，那就太棒了。

但当然首先也是最重要的事情是获得一个好的 TOML 插件：1st_place_medal：

另一个标准类型库也将保证类型问题的标准错误消息。

检查可以在其他插件中轻松完成（一旦 #2963 完成）。 如果插件只检查并失败并显示漂亮的错误消息，则交互很少/没有交互。

听起来像是 libease 转换部分的工作

是的，可能来自 TOML 的一些东西可以转到 libease 或 libmeta。

IMO，存储插件不应该依赖任何其他插件。

对于二进制我还不确定（因为它可能是默认后端不需要的东西），对于所有其他功能，这也是我的结论。 不过，这个结论还没有被广泛接受（@sanssecours？），也没有记录在案。

这就是为什么我提出了一个图书馆。 提供一个可以完成工作的库比仅仅给出插件必须做什么的非正式描述（甚至正式规范）要好得多。 特别是，如果规范可能会随着时间的推移而改变。

这取决于：如果有大量有效的可能性，教程/描述可能比以某种方式试图提供这种灵活性的复杂库更好。 对于序列化，存在大量有效的可能性，其中许多具有简单的实现（例如，简单地调用带有一些参数的 elektraFormat）到复杂的实现（例如，如果它们支持许多方便的表示）。

为什么要取消已经实现的功能？

Elektra 目前因维护过多代码而崩溃。 我们删除的每一行无用（意味着没有人使用它）的代码行都会使 Elektra 变得更好。

不幸的是，即使代码在插件中分离也会产生问题：例如，在构建服务器上或一旦用户尝试使用它，就会出现不需要的交互/丢失文档/...

我们不能发布我们目前拥有的所有 1.0 版本，届时 Elektra 会令人失望。 我们需要摆脱一切不需要的东西。 我们感谢您能做的每一次清理工作。

这也是TOML会取代INI的原因。 第3491章

让插件自己做检查。

这很少是一个好的解决方案。 它变得非常不一致，添加插件的顺序可能会产生不同的结果。 这样的代码是否已经存在于某处？

@bauhaus93写道：

除了布尔值，TOML 插件还在读取时设置 string、double 和 (unsigned_)long_long 类型。

但这一切都是在没有类型插件的情况下自行完成的吗？ 类型插件是做什么用的？

您必须改为更改 origvalue 元键。

是的，我们还没有一个很好的解决方案（#3056）。 keySetString 删除了 origvalue 但不知何故行为仍然不像用户期望的那样。

目前，在编写时，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作为输入并且只在kdbGet产生0 / 1 kdbGet并且它只接受0 / 1并且只在kdbSet产生true / false kdbSet 。 这将符合 Elektra 规范和布尔值的 TOML 规范。 但是用户可能会期望kdb set /some/key/mounted/with/toml true会起作用。 然而，事实并非如此。 使用正确的type它可能会工作，但很快就会变得尴尬。 例如，如果密钥之前确实存在怎么办。 然后没有type密钥并且type插件只是忽略它， toml收到true并抱怨true是无效的布尔...

这只是表明存储插件必须能够处理存储格式支持的所有类型以及相关的转换，而无需使用任何其他插件。

Elektra 目前因维护过多代码而崩溃。 我们删除的每一行无用（意味着没有人使用它）的代码行都会使 Elektra 变得更好。

这是一个公平的观点，尽管我不认为简单地删除代码是正确的解决方案。 至少在插件方面不是。 在核心中，我同意，LOC 越少越好。 对于插件，我们可以很容易地说插件或它的某些部分是实验性的。

IMO，存储插件不应该依赖任何其他插件。

不过，这个结论还没有被广泛接受（@sanssecours？），也没有记录在案。

据我所知，文档中没有任何地方声明存储插件不应依赖其他插件。 从关注点分离的角度来看，我也不认为这很好。 在我看来，编写一个好的存储插件已经是相当多的工作了。 要求存储插件处理类型转换、目录键和二进制数据（Base64 编码）并不会使这项工作变得更容易。

从关注点分离的角度来看，我也不认为这很好。 在我看来，编写一个好的存储插件已经是相当多的工作了。

这就是辅助库的意义所在。 它分离出公共代码，从而提供（一些）关注点分离以及使插件的开发更容易。

关于@markus2330担心开发通用库比类似插件更难：这实际上是错误的，因为您可以简单地提供当前elektraTypeGet函数的稍微修改版本作为库。 修改只是因为我们需要用KeySet * config替换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/mounted/with/toml true 会起作用。

不，用户不应该期望那样。 在 Elektra 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插件的参数。 虽然我仍然想要一个接口，通过它插件可以一次只工作一个键，但这可以节省一些内存，也可能节省性能。 （但那是另一个问题）

有很多种格式很常见。

你有例子吗？

当您扩展规范（从具有值的键创建子键）时，它们会非常有用。

是的，但在这种情况下，我会推荐一个“非此即彼”的解决方案（来自最终用户 POV）。 要么使用带有单个值的旧键，要么使用带有子键的新版本。 否则配置可能会令人困惑。

需要明确的是，我不认为永远不应该使用带有值的非叶键，但是如果可能的话应该避免使用它们，并且很少（如果有的话）是首选的解决方案。

但不适用于“目录值”插件，因为转义不起作用

在#3256 中，我建议使用元数据来解决转义问题。 还有我来自 #3223 的想法可以解决转义问题（对于每个用例，而不仅仅是directoryvalue ）以及其他一些事情。 另见（非常正式的）提案。 我将在今天或明天在该文档中添加简单的英语解释，因为我仍然非常支持这些更改。

@sanssecours YAML 插件如何处理类型转换？

Yan LR 和 YAML CPP 使用type插件来处理布尔值。 YAML CPP 还使用base64插件来处理二进制数据。

base64 不是编码二进制数据的唯一方法。 对于需要 base64 的标准，它可以是硬编码的。 （ @sanssecours是 YAML 的情况吗？）

是的，据我所知，YAML 中的二进制数据总是使用 Base64 编码。

[带值的非叶键] 你有例子吗？

XML 和大多数 INI 方言（因为即使[key]存在，它们也允许key=value ）

是的，但在这种情况下，我会推荐一个“非此即彼”的解决方案（来自最终用户 POV）。 要么使用带有单个值的旧键，要么使用带有子键的新版本。 否则配置可能会令人困惑。

是的，这听起来很合理。 一旦您知道某物是一个部分，您通常会将值移动到该部分内的某处。

例如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，我会评论它。 否则，我们应该退后一步，考虑我们力所能及的可行解决方案。

我会开始一个PR，但是在可预见的时间内我是否有时间（一个人）完成它，我不能说。
我已经有一个本地分支，其中对keyBaseName 、 keySetBaseName和keyAddBaseName所有调用已被keyLastUnescapedPart 、 keySetLastUnescapedPart / keySetLastLiteralPart替换keyAddUnescapedPart / keyAddLiteralPart 。 我在编写第一个提案后使用半自动正则表达式替换创建了它。

但是在那个分支中，新函数只是旧函数的#define s，所以仍然需要编写实际的实现，然后测试，可能还需要更新存储插件。

对我来说最大的问题是存储插件。 我可以实现对核心和测试的更新，也许还有一个存储插件。 但我更愿意，如果我不必研究所有存储插件的代码并弄清楚所有格式的所有复杂性。

顺便提一句。 提案的第一部分实际上是一个关于键名如何工作的精彩教程。 将此作为教程会很棒。

这就是我这样写的原因。 我的计划是在 #3447 中为文档重用该提案的部分内容。 我不能以 1:1 的比例使用它，因为我遗漏了一些非常重要的部分（例如规范与非规范）。

我需要直言不讳，不要给你任何错误的希望：正如你在 LCDproc 中看到的，不会发生其他人正在完成任务的情况，尤其是在他们很乏味的时候。 销毁除一个之外的所有存储插件的 PR 是不可合并的。 并且存储插件并没有从这个 PR 中获得太多好处，实际上它们变得“更糟”，因为它们会突然对它们现在可以解析的文件产生语法错误。 这并不意味着它总体上是一个坏主意。 通过一些改进，它可能比现状更好，但我只是不明白我们如何能够通过我们现在拥有的许多其他紧迫的重要未决任务来完成如此大的任务。

所以请让我们专注于#3447（docu），最终完成#2969，改进TOML插件和我们1.0所需的其他重要主题（https://github.com/ElektraInitiative/libelektra/milestone/12和https:// github.com/ElektraInitiative/libelektra/milestone/14)。 一旦这看起来不错，我们就可以看到我们可以完成哪些其他想法。

对我来说，这次讨论的结论是，肯定需要库来使编写存储插件更容易，因为插件方法不起作用（除了二进制文件）。 这个结论应该在存储插件教程中。
@bauhaus93你能接任务继续存储插件教程吗？ 你现在有很多见识，这是看toml插件源码是看不出来的。

销毁除一个之外的所有存储插件的 PR 是不可合并的。

我没想到有人会合并这样的 PR……我只是说如果其他人可以帮助更新存储插件就好了。 理想情况下是插件的原作者。 #3491之后，一些更复杂的存储插件无论如何都会被删除，所以整个任务会更容易。

并且存储插件并没有从这个 PR 中获得太多好处，实际上它们变得“更糟”，因为它们会突然对它们现在可以解析的文件产生语法错误。

这不应该是这种情况。 提案的最后甚至还有部分说明。 AFAIK不应该有一个情况下，如果一个存储插件必须拒绝的文件，因为它不能被翻译成KeySet 。

一个例外是格式，它直接使用 Elektra 的键名（转义或未转义）。 在此提议之后，这些可能会接受比以前更少的文件。 但由于这些文件的语法总是依赖于键名的语法，这完全在意料之中。

通过一些改进，它可能比现状更好，但我只是不明白我们如何能够通过我们现在拥有的许多其他紧迫的重要未决任务来完成如此大的任务。

我没想到这个提议会立即被采纳。 但我认为我们绝对应该考虑在1.0

所以请让我们专注于#3447（docu），最终完成#2969，改进TOML插件和1.0我们需要的其他重要主题

我完全同意。 不过话说回来，我们还是要考虑一下，因为1.0发布后，在相当长的一段时间内，添加破坏性更改将是非常困难的。

对我来说，这次讨论的结论是肯定需要库来更容易地编写存储插件

👍

除了二进制是要看到的

IMO，二进制值的情况非常不同。 它是一个 1:1 的键值转换，与许多其他（ rgbcolor 、 macaddr 、 ipaddr等）一样，因此插件实际上非常适合这里。 然而，就像我说的，一个新的插件 API 一次只处理一个键可能是一种改进。 但这可以很容易地在 1.0 之后添加，因为如果正确完成，它不会是一个破坏性的变化。

大多数 -> 必须？

是的，我也有同样的看法：一旦 1.0 发布，这种改变就会发生是不现实的（1.0 的全部目的是冻结这样的决定，以便其他人可以依赖它）并且在此之前进行这样的改进会很好. 但正如所说：我们真的需要专注于完成关键的事情，而不是在用我们目前的人力无法赢得的好战中失去精力。