Libelektra: タイプのライブラリ

提案に基づいて図書館を作るという例外的な方法だと思います。 プラグイン間で共通の機能を抽出し、それからライブラリを作成する方がはるかに理にかなっています。 @ bauhaus93のTOMLプラグインには、ライブラリに入れるのに非常に意味のあるコードがたくさんあります（コメント処理コードなど）。

誤解しないでください、@ bauhaus93への良い入力です。 また、同じ機能を必要とする2つ目のプラグインがある場合は、それをライブラリに配置する必要があります。 ただし、ライブラリの作成はプラグイン固有のコードを作成するよりもはるかに手間がかかり、実際に少なくとも2人の顧客がいる場合にのみ作業を行う必要があります。

@ bauhaus93タイプライブラリを使用することにすぐにメリットが見られない場合（たとえば、別のプラグインで再利用する場合）、問題を閉じてください。

同じ機能を必要とする2番目のプラグインがある場合は、それをライブラリに配置する必要があります

2番目のプラグインの開発者が、最初のプラグインを見つける場所と、すべてを壊すことなくそこからコードを抽出する方法を知っている限り、それは良い戦略です。 悲しいことに、これはしばしばそうではありません。 特に、ライブラリを使用できるように、最初のプラグインを大幅に変更する必要がある場合が多いためです。

また、一部の作業はすでに完了しているため、ライブラリを使用すると、実際に誰かが新しいストレージプラグインを作成するように促される可能性があります。

しかし、私はこれにlow priorityタグを付けました。これは、その多くの作業を知っていて、おそらく誰もそれをやりたくないからです。

タイプについては、10進数以外の整数（2進数/ 8進数/ 16進数）または日時（TOMLはRFC 3339日時を使用）の検証/変換を除いて、再利用性についてはよくわかりません。
種類に関係のない、私は、例えば（に--書き込むことがキーセットの製造で、いくつかの再利用を参照してください。機能の更新/追加することをarray metakeysを、削除array行方不明無効配列または完全なのmetakeys comment/#Xメタキーデータ）。

まだ気付いていないかもしれませんが、typeプラグインが行うブール値の正規化にも問題がある可能性があります。 ほとんどのフォーマットはtrue / false使用しますが、Elektraは1 / 0を使用するため、これはおそらく最も再利用されるコードです。 yamlcppは、ブール値が整数に変換されないように、またはその逆（またはそれらの行に沿ったもの）にならないように、特別なコードを追加する必要があったと思います。

そうそう、それを忘れてしまったので、TOMLプラグインもこれらの値を正規化する必要があります。

問題は、値を正規化する必要があるということだけではありません。 また、 kdbSetフェーズではtomlプラグインの前に実行されるため、 typeプラグインが何をするかを正確に知る必要があります。 実装したかどうかはわかりませんが、 typeプラグインが1 / 0またはtrue /のみを生成することも確認する必要がありますfalse kdbSetフェーズでは、ユーザーが提供した構成に関係なく、 false 。 それ以外の場合、ユーザーはカスタムのtrue値とfalse値を設定できるため、 tomlはtypeプラグイン構成を解析できる必要があります（以下のテストケースを参照）。

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 1を受け取ります（ toml場合もあります）が、 kdbSet tを返しますkdbSet 。 これは、 true = 0とfalse = 1を定義しているユーザーにまで及ぶ可能性があり、 tomlプラグインを完全に混乱させることになります。 （すべてのブール値はkdbSetごとに反転すると思います）

この非常に複雑な相互作用が、 typeプラグインが型を持たないストレージ形式用であり、型を持っているものはtype使用を明示的に禁止する必要があると私が考える理由です。 しかし、それを実現可能にするには、ストレージプラグイン内の型、つまり型ライブラリをサポートする簡単な方法が必要です。

tomlプラグインも16進数を処理するため、 hexnumberプラグインの使用も明示的に禁止する必要があります。 （その場合、問題が発生する可能性は低いと思いますが）

また、一部の作業はすでに完了しているため、ライブラリを使用すると、実際に誰かが新しいストレージプラグインを作成するように促される可能性があります。

ほとんどのユーザーはおそらく文法を書きたいだけで、残りは魔法のようにそれ自体で起こるはずです。 @ bauhaus93のTOMLプラグインが実際にこの目標をどこまで達成したのだろうか。 TOMLプラグインのコードベースを使用して非TOMLプラグインを作成するのは興味深いことです。 ただし、タイプライブラリだけでも、「ストレージプラグインの作成」という大きなタスクに非常に役立つことに特化しているように思えます。

タイプについては、10進数以外の整数（2進数/ 8進数/ 16進数）または日時（TOMLはRFC 3339日時を使用）の検証/変換を除いて、再利用性についてはよくわかりません。

日付/時刻は検証のためにのみElektraに存在しましたが、RFC2822のみがサポートされていました。 日付プラグインはパーサーを再利用してRFC3339を検証できますが、これは非常に低い優先度と見なされます。

もう少しエキサイティングなのは、（TOML）日付のキーからのkeyGetDateTime(Key *k, struct tm *tm)ようなものです。

タイプとは関係なく、作成するKeySetの準備にある程度の再利用性が見られます（たとえば、配列メタキーを更新/追加したり、無効な配列の配列メタキーを削除したり、欠落しているコメント/＃Xメタキーデータを完全にしたりする関数）。

はい、それは面白いかもしれません。 しかし、さらに魅力的なのは、文法を直接変更してコードをできるだけ少なくする可能性です：wink：

まだ気付いていないかもしれませんが、typeプラグインが行うブール値の正規化にも問題がある可能性があります。

不足しているのは、doc / tutorials / storage-plugins.mdのチュートリアル/説明です。これは、ストレージプラグインが実際に依存する必要があるプラグインの最新のビューを提供します。 ＃2330は、「バイナリ」が必要であり、デフォルトのストレージとして適切であるかどうかを示します。

また、タイププラグインはkdbSetフェーズのtomlプラグインの前に実行されるため、タイププラグインが何をするのかを正確に知る必要があります。

おそらく、ストレージプラグインは、タイププラグインの使用を停止し、単純に正規化を実行する必要があります（形式のtrue / falseからElektraの1/0など）。 @ bauhaus93タイププラグインの他のどの機能を使用しますか？

これは、ユーザーがtrue = 0およびfalse = 1と定義している場合に限り、tomlプラグインを完全に混乱させる可能性があります。

タイププラグインの機能を減らすことに賛成です。 どちらかといえば、いくつかの追加のtrue / false値は、ユーザーが定義できる必要があります（以前は明らかにtrue / false値ではありませんでした）。

tomlプラグインは16進数も処理するため、おそらく16進数プラグインの使用も明示的に禁止する必要があります。 （その場合、問題が発生する可能性は低いと思いますが）

プラグインが一緒に機能しないことを表現する方法はありません（このような機能があると、マウントがはるかに複雑になります。また、どのプラグインがどのプラグインで機能するかを示すテーブルを維持するのも大変です）。 しかし、TOMLプラグインにはすでにこの機能とそれ以上の機能（たとえば2進数）があるため、おそらく誰もそれらを一緒に使用する考えを持っていないでしょう。

ほとんどのユーザーはおそらく文法を書きたいだけで、残りは魔法のようにそれ自体で起こるはずです。

それは少し魔法のように思えます。 変更されたYaccまたはANTLR文法に基づくカスタムコードジェネレーターで可能かもしれません。 しかし、JSON、XML、TOML、 ednなどの非常に異なる形式の文法から単純にKeySetを作成するコードを作成する方法はないと思います。 @ 'sanssecoursが見つけたように、標準の文法形式で表現するのが非常に難しいYAMLのような形式もあります。

ただし、タイプライブラリだけでも、「ストレージプラグインの作成」という大きなタスクに非常に役立つことに特化しているように思えます。

もちろん、ライブラリを一般的なstorageライブラリに拡張して、ストレージプラグイン用のより多くのヘルパー関数を提供することもできます（たとえば、 stdin / stdoutとインポート/エクスポート用のパイプを処理します）。 タイプのものはその一部になります。

また、タイプのものがどれほど複雑になる可能性があるかを過小評価していると思います。 標準の型ライブラリがある場合は、型システムを拡張することも簡単になります。たとえば、解析のオーバーヘッドを減らすために、事前に解析された整数のバイナリバージョンを（文字列バージョンに）格納することもできます。 storageライブラリは、Elektra開発者によって維持されているため、（必要に応じて）内部APIを使用することもできます。

別の標準タイプライブラリも、タイプの問題に対する標準エラーメッセージを保証します。 したがって、エンドユーザーにとっても利点があります。

もう少しエキサイティングなのは、keyGetDateTime（Key * k、struct tm * tm）のようなものです。

libeaseの変換部分の仕事のように聞こえます（ elektraKeyToDateTime (const Key * key, struct tm * dateTime) ）。

@ bauhaus93そこにある関数は、 tomlにも役立つ可能性があります。 これらは、たとえばelektraKeyToFloatとelektraFloatToString完全かつロスレスでラウンドトリップするように設計されており（文字列のfloatで開始するかどうかに関係なく）、高レベルAPIでも使用されます。 したがって、 tomlがelektra*ToStringでキーを作成する場合、高レベルAPIで確実に正しく読み取ることができ、 toml生成されたhighlevel APIで確実に正しく読み取ることができます。 elektraKeyTo* 。

ストレージプラグインが実際に依存する必要があるプラグインの最新ビュー。

IMO、ストレージプラグインは、他のプラグインに「依存」してはなりません。 ストレージプラグインは他のプラグインで拡張できますが、スタンドアロンで動作するのが理想的です。

バイナリキーを扱う場合でも、ストレージ/タイプライブラリによってより適切に解決されます。 ここでも、エラーメッセージなどのベースライン標準が保証されます。また、それを必要としない形式でのbinaryプラグインの使用も回避されます。 binaryとたとえばquickdumpを組み合わせると機能しますが、速度とストレージサイズの両方に問題があります。

おそらく、ストレージプラグインはタイププラグインの使用を停止し、単純に自分で正規化を行う必要があります

だから私は図書館を提案しました。 プラグインが実行する必要があることの非公式な説明（または正式な仕様）を与えるよりも、作業を実行するライブラリを提供する方がはるかに優れています。 特に、仕様が時間の経過とともに変更される可能性がある場合。

タイププラグインの機能を減らすことに賛成です。

すでに実装されている機能を削除するのはなぜですか？ もともとは別のbooleanプラグインを用意するというアイデアでしたが、プラグインの順序などが原因で問題も発生しました。

どちらかといえば、いくつかの追加のtrue / false値は、ユーザーが定義できる必要があります（以前は明らかにtrue / false値ではありませんでした）。

本当にその必要はありません。 複数のプラグインがブール値を定義している場合にのみ問題が発生します。

true = 0とfalse = 1さえ完全に問題ありません。 Elektra自体は、「 1が唯一の真の値であり、 0が唯一の偽の値である」としてブール値を罰金します。

プラグインが一緒に機能しないことを表現する方法はありません（このような機能があると、マウントがはるかに複雑になります。また、どのプラグインがどのプラグインで機能するかを示すテーブルを維持するのも大変です）。

同意しません。 もちろん、完全なリストは不可能ですが（結局、サードパーティのプラグインもあります）、解決策は簡単です。 プラグインにチェックを任せます。 elektra<Plugin>Getまたはkdb mount間に呼び出される別の関数のいずれか。

ブール値に加えて、TOMLプラグインは、読み取り時に文字列、double、および（unsigned_）long_long型も設定します。

私は@kodebachに同意します。相互作用が難しいため、 typeプラグインは組み込み型システムのないプラグインでのみ使用する必要があります。
例えば。 TOMLプラグインは、10進数以外の値を読み取るときに、整数のtypeメタキーを設定します（10進数に変換し、10進数以外の表現をorigvalueに格納します）。 ただし、このような型指定された値をkdb set変更したい場合（および2進数/ 8進数/ 16進数の値で変更したい場合）、 typeであるため、直接（キー値を設定して）変更することはできません。 origvalueメタキーを変更する必要があります。 （新しい値を設定する前にtypeメタキーを削除しても、メタキーは読み取り時に再設定されるため、機能しません。）

問題は、値を正規化する必要があるということだけではありません。 また、タイププラグインはkdbSetフェーズのtomlプラグインの前に実行されるため、タイププラグインが何をするのかを正確に知る必要があります。 実装したかどうかはわかりませんが、ユーザーが指定した構成に関係なく、タイププラグインがkdbSetフェーズで1/0またはtrue / falseのみを生成することも確認する必要があります。 そうしないと、ユーザーがカスタムのtrue値とfalse値を設定できるため、tomlはタイププラグインの構成を解析できる必要があります（以下のテストケースを参照）。

ええ、私はすでに、ユーザー定義のブール値を実際にチェックできるかどうか/どのようにできるのか疑問に思いました。 現在、書き込み時に、TOMLプラグインは"1"と"true"値のみをtrueと見なし、残りはfalseと見なされます。

@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プラグインは、読み取り時に文字列、double、および（unsigned_）long_long型も設定します。

しかし、それはすべて、タイププラグインなしでそれ自体で実行されますか？ タイププラグインは何に使用されますか？

代わりに、origvalueメタキーを変更する必要があります。

はい、ここにはまだ良い解決策がありません（＃3056）。 keySetStringはorigvalueを削除しますが、どういうわけか、動作はユーザーが期待するとおりではありません。

現在、書き込み時に、TOMLプラグインは「1」と「true」の値のみをtrueと見なし、残りはfalseと見なされます。

おそらく、もっと厳密にして、「0」や「1」以外のすべてに失敗する必要があります。 TOMLファイル自体でも、「true」と「false」のみを許可し、それ以外は許可しませんか？

しかし、それはすべて、タイププラグインなしでそれ自体で実行されますか？ タイププラグインは何に使用されますか？

はい、それはそれ自体でそれを行います、異なるタイプは字句解析中に一致します。 ただし、decimal / double値がオーバーフロー/アンダーフローlong_long / doubleであるかどうかはチェックされないため、 typeプラグインによって実行されると思います。

おそらく、もっと厳密にして、「0」や「1」以外のすべてに失敗する必要があります。 TOMLファイル自体でも、「true」と「false」のみを許可し、それ以外は許可しませんか？

はい、もっと厳しくすることができます。 ファイル自体では、 trueまたはfalseがブール値として書き込まれます。

他のすべての機能については、これも私の結論です。

その場合、 typeライブラリが必要です。 そうしないと、型のある形式のストレージプラグインは、型のものを再実装することになります（別のプラグインに依存することは問題外であるため）。

有効な可能性が非常に多い場合は、チュートリアル/説明の方が適している可能性があります

ただし、その場合は、別のプラグインも解決策ではありません。両方のプラグインで考慮する必要のある相互作用が多数存在する可能性があるためです。

そのようなコードはすでにどこかに存在しますか？

ちなみに、プラグインが他のどのプラグインがマウントされているかを検出できるかどうかさえわかりません。

しかし、それはすべて、タイププラグインなしでそれ自体で実行されますか？ タイププラグインは何に使用されますか？

はい、それはそれ自体でそれを行います、異なるタイプは字句解析中に一致します。 ただし、decimal / double値がオーバーフロー/アンダーフローlong_long / doubleであるかどうかはチェックされないため、 typeプラグインによって実行されると思います。

はいtypeは範囲チェックも行い、 float / doubleやenumのような他のものを検証します。

おそらく、もっと厳密にして、「0」や「1」以外のすべてに失敗する必要があります。 TOMLファイル自体でも、「true」と「false」のみを許可し、それ以外は許可しませんか？

そして、それはまさに、型、より具体的には変換/正規化のこれらの非常に複雑で複雑なケースの1つです。

toml入力としてtrue / false tomlのみを受け入れ、 kdbGetで0 / 1のみを生成すると仮定します。受け入れるだけ0 / 1のみ生成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関数のわずかに変更されたバージョンをライブラリとして簡単に提供できるため、これは事実上間違っています。 Plugin * handleをKeySet * configに置き換える必要があるため、変更が必要になるだけです。 これですべての問題が解決するわけではありませんが、少なくともストレージプラグインでタイプの処理がいつどのように行われるかを正確に制御できます。

例として、 tomlは、TOMLタイプのシステムを使用せずにtypeを使用するINIフォールバックモードと、 elektraTypeGet提供する通常のTOMLモードを持つことができます。すべてがTOML仕様に準拠していることを保証する非常に正確な構成を備えています。

つまり、ライブラリは、ストレージプラグインの観点から見ると、プラグインよりもはるかに柔軟です。 少なくとも現在のプラグイン構成の可能性については。

ストレージプラグインが型変換、ディレクトリキー、およびバイナリデータ（Base64エンコーディング）を処理することを要求しても、その作業は簡単にはなりません。

これを分解しましょう：

• バイナリデータ：次のようなことを行うための作業は実際にはありません。
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  ストレージプラグインが他のプラグインがすべての状況でマウントされることを強制でき、バイナリキーがないと単純に想定できる限り、別のプラグインも機能します。 プラグインがそれでもkeyIsBinaryを呼び出してエラーをスローする必要がある場合、このソリューションには何のメリットもありません。 また、別のバイナリプラグインがKeySet全体を一度に変換する必要があるのも好きではありません。これは、すべてのBase64キーがかなりのメモリを浪費するためです。
• ディレクトリキー：最初に、値を持つこれらの非リーフキーは、ほとんどすべての状況で奇妙であり、実際には避けることをお勧めします。 ＃3256で述べたように、これらのキーの処理に関しては、ライブラリがこの場合にはるかに適していると思います。 メモリと処理のオーバーヘッド、マウントポイントの構成と柔軟性を不必要に複雑にするなど、多くの理由があります。 @ markus2330 （やや）はこの点で私に同意しているようです。
• 型：ネイティブ型システムを持つフォーマットのストレージプラグインは、型に対して少なくともいくつかの作業を行う必要があります。 これは、最初から完全な変換を行うことから、ライブラリを呼び出すこと、別のプラグインを構成することまで多岐にわたります。 すべてがうまく機能することは決して不可能です。 タイプの非常に詳細な正式な仕様があり、タイププラグインを直接構成する必要がない場合でも、ストレージプラグインは何らかの方法でこの仕様を実装する必要があります。

ただし、decimal / double値がover- / underflow long_long / doubleであるかどうかはチェックされないため、typepluginによって実行されると思います。

さて、基本的にはチェックにのみ使用します。

しかし、その場合、別のプラグインも解決策ではありません

いいえ、残念ながら個別のプラグインは解決策ではありません。 そこで失敗しました。 現在の解決策は、すべてのストレージプラグインがdoc / tutorials / storage-plugins.mdに基づいてすべて（バイナリ処理を除く）を実装することです。

しかし、ユーザーはおそらくkdb set / some / key / Mounted / with / tomltrueが機能することを期待するでしょう。

いいえ、ユーザーはそれを期待するべきではありません。 Elektraでは1/0はtrue / falseです。 ストレージプラグインのみがこれを他の何かにマップする可能性があります。

理論的根拠：少なくとも仕様レベルでは1/0のみが機能しているため、他の場所（ストレージプラグインを除く）でtrue / falseを機能させることは混乱を招くだけです。

これは、ストレージプラグインが、他のプラグインを使用せずに、ストレージ形式がサポートするすべてのタイプと関連する変換を処理できなければならないことを示しています。

はい私は同意する。

単にコードを削除することが正しい解決策だとは思いませんが、それは公正な点です。

もちろん、「正しい」コードを削除する必要があります。それは、それを実現したり、エレクトラの他の部分に問題を引き起こしたりすることなく、期待を与えるコードです。 また、タイププラグインの一部の機能は、Elektraの他の部分と一緒に問題を引き起こすようです。

少なくともプラグインに関してはそうではありません。 コア内では、LOCが少ないほど良いと私は同意します。 プラグインの場合、プラグインまたはその一部は実験的なものであると簡単に言えます。

残念ながら、これは（まだ*）機能しません。 人々はプラグインのステータスを正しく判断しません。たとえば、最近では、メンテナンスされておらず、バグが多いINIプラグイン、さらに悪いことに、推奨されていないレガシーxmltoolプラグインが完全に機能すると考えられていた＃3472を参照してください。

• ＃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 （ある程度）はこの点で私に同意しているようです。

私はストレージプラグインがそれを処理する必要があることに同意します（おそらくライブラリではありますが、エスケープは機能せず、正しいエスケープはストレージプラグインの主な仕事の1つであるため、「directoryvalue」プラグインではそうではありません）。

さて、基本的にはチェックにのみ使用します。

「 tomlプラグインはtypeプラグインを使用する」というフレーズに同意しtoml 。 現在のバージョンでは、 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プラグインの議論です。 プラグインが一度に1つのキーを処理できるインターフェイスが必要ですが、これにより、メモリをいくらか節約でき、パフォーマンスも節約できる可能性があります。 （しかし、それは別の問題です）

多くの形式で非常に一般的です。

例はありますか？

また、仕様を拡張する場合（値を持つキーからサブキーを作成する場合）に非常に役立ちます。

本当ですが、その場合は、（エンドユーザーのPOVからの）「どちらか一方」のソリューションをお勧めします。 単一の値で古いキーを使用するか、サブキーで新しいバージョンを使用します。 そうしないと、設定が混乱する可能性があります。

明確にするために、値を持つ非リーフキーは絶対に使用すべきではないと思いますが、可能であれば回避する必要があり、まれに（あるとしても）推奨されるソリューションです。

ただし、エスケープが機能しないため、「directoryvalue」プラグインでは使用できません

＃3256で、エスケープの問題を解決するためにメタデータを使用することを提案しました。 また、エスケープの問題（ directoryvalueだけでなくすべてのユースケース）やその他の問題を解決する＃3223のアイデアもあります。 （非常に正式な）提案も参照してください。 私はまだこれらの変更に非常に賛成しているので、今日または明日、その文書にわかりやすい英語の説明を追加します。

@sanssecours YAMLプラグインは型変換をどのように処理しますか？

YanLRとYAMLCPPは、ブール値にtypeプラグインを使用します。 YAML CPPは、バイナリデータにbase64プラグインも使用します。

base64は、バイナリデータをエンコードする唯一の方法ではありません。 base64が必要な標準の場合、ハードコーディングできます。 （ @sanssecours YAMLの場合ですか？）

はい、私が知る限り、YAMLのバイナリデータは常にBase64エンコーディングを使用します。

[値のある非リーフキー]例はありますか？

XMLおよびほとんどのINI方言（ [key]が存在する場合でもkey=valueを許可するため）

本当ですが、その場合は、（エンドユーザーのPOVからの）「どちらか一方」のソリューションをお勧めします。 単一の値で古いキーを使用するか、サブキーで新しいバージョンを使用します。 そうしないと、設定が混乱する可能性があります。

はい、それは合理的に聞こえます。 何かがセクションであることがわかったら、通常、値をセクション内のどこかに移動します。

たとえば、 deluser.confはBACKUP = 0とBACKUP_TO = "."ます。 セクションを使用すると、ほとんどのアプリケーションは単にBACKUPではなくBACKUP_ENABLE使用します。

また、エスケープの問題（ directoryvalueだけでなくすべてのユースケース）やその他の問題を解決する＃3223のアイデアもあります。

＃3223の提案を更新しました。 理解しやすくなったと思います（まだ非常に長いです）。

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

大きな問題は、誰がこれらすべてを実装するかということです。 それは現状からかなり離れています。つまり、多くの作業です（用語の変更だけでも膨大な量の作業です）。 実装したい場合は、提案書を使ってPRを作成してコメントします。 それ以外の場合は、一歩下がって、手の届く範囲で実行可能なソリューションについて考える必要があります。

ところで。 提案の最初の部分は、実際にはキー名がどのように機能するかについての素晴らしいチュートリアルです。 これをチュートリアルとして持っていると素晴らしいでしょう。 ：sparkling_heart：

大きな問題は、誰がこれらすべてを実装するかということです。

それは常に問題です...

それは現状からかなり離れています。つまり、多くの作業です（用語の変更だけでも膨大な量の作業です）。

用語の変更は間違いなく最大の部分であり、特にすべてのドキュメントを変更します。 ただし、これは1人で行う必要はありません。 これらの変更は非常に単純で、面倒なので、コードに関する広範な知識がなくても、誰でも支援できます。 ほとんどの場合、それはすべてのドキュメントを読み、「ベース名」のようなものの出現を置き換えることを意味します。

実装したい場合は、提案書を使ってPRを作成してコメントします。 それ以外の場合は、一歩下がって、手の届く範囲で実行可能なソリューションについて考える必要があります。

PRを始めますが、予見できる範囲で（一人で）終わらせる時間があるかどうかはわかりません。
keyBaseName 、 keySetBaseName 、 keyAddBaseNameへのすべての呼び出しがkeyLastUnescapedPart 、 keySetLastUnescapedPart / keySetLastLiteralPart置き換えられたローカルブランチがすでにありますkeyAddUnescapedPart / keyAddLiteralPart 。 最初の提案を書いた後、半自動の正規表現置換を使用してそれを作成しました。

しかし、そのブランチでは、新しい関数は古い関数に対して#defineであるため、実際の実装を作成してから、テストとおそらくストレージプラグインを更新する必要があります。

私にとって最大の問題は、ストレージプラグインです。 コアとテスト、そしておそらく1つのストレージプラグインの更新を実装できます。 しかし、すべてのストレージプラグインのコードを調べて、すべての形式のすべての複雑さを理解する必要がない場合は、私は好みます。

ところで。 提案の最初の部分は、実際にはキー名がどのように機能するかについての素晴らしいチュートリアルです。 これをチュートリアルとして持っていると素晴らしいでしょう。

だから私はこのように書いたのです。 私の計画は、この提案の一部を＃3447のドキュメントに再利用することでした。 いくつかの非常に重要な部分（たとえば、正規と非正規）を省略したため、1：1で使用することはできません。

私は率直に話し、間違った希望を与えないようにする必要があります。LCDprocで見たように、他の人がタスクを完了するためにジャンプしていることはありません。特に退屈なときはそうではありません。 1つを除くすべてのストレージプラグインを破棄するPRはマージできません。 また、ストレージプラグインは、このPRからあまりメリットがありません。実際には、現在解析できるファイルで突然構文エラーが発生するという意味で、「悪化」します。 これは、それが全体的に悪い考えであることを意味するものではありません。 いくつかの改良を加えると、現状よりも優れているかもしれませんが、現在私たちが持っている他の多くの緊急の重要なオープンタスクでこのような大きなタスクを実行する方法がわかりません。

ですから、＃3447（docu）に集中して、最終的に＃2969を完成させ、TOMLプラグインと1.0に必要なその他の重要なトピックを改善してください（https://github.com/ElektraInitiative/libelektra/milestone/12およびhttps：// github.com/ElektraInitiative/libelektra/milestone/14）。 これが良さそうになると、他にどのようなアイデアを実現できるかがわかります。

私にとって、この議論の結論は、プラグインアプローチが機能しなかったため（バイナリを除いて）、ストレージプラグインを簡単に作成できるようにするライブラリが確実に必要であるということです。 この結論は、ストレージプラグインのチュートリアルにあるはずです。
@ bauhaus93ストレージプラグインのチュートリアルを続行するタスクを実行できますか？ これで多くの洞察が得られましたが、tomlプラグインのソースコードを見てもわかりません。

1つを除くすべてのストレージプラグインを破棄するPRはマージできません。

誰かがそのようなPRをマージすることを期待していませんでした...他の人がストレージプラグインの更新を手伝ってくれるといいと言っただけです。 理想的には、プラグインの元の作成者です。 ＃3491以降、より複雑なストレージプラグインのいくつかはとにかく削除されるため、タスク全体が簡単になります。

また、ストレージプラグインは、このPRからあまりメリットがありません。実際には、現在解析できるファイルで突然構文エラーが発生するという意味で、「悪化」します。

これは当てはまらないはずです。 提案の最後に部分的な説明さえあります。 それはに翻訳することができないので、私の知る限り、ストレージ・プラグインはファイルを拒否しなければならない場合、存在してはならKeySet 。

唯一の例外は、Elektraのキー名（エスケープされているかエスケープされていないか）を直接使用するフォーマットです。 これらは、この提案の後、以前よりも少ないファイルを受け入れる可能性があります。 ただし、これらのファイルの構文は常にキー名の構文に依存しているため、これは完全に予想されることです。

いくつかの改良を加えると、現状よりも優れているかもしれませんが、現在私たちが持っている他の多くの緊急の重要なオープンタスクでこのような大きなタスクを実行する方法がわかりません。

この提案がすぐに採用されるとは思ってもみませんでした。 しかし、1.0より前に実装することを確実に検討する必要があると思います。 1.0がリリースされると、提案は大きな大きな変化になります。 Elektraの対象読者を考えると、1.0から1年または2年後でもバージョン2.0をリリースすることは（それより前に気にしないでください）良い考えではないと思います。

ですから、＃3447（docu）に集中して、最終的に＃2969を完成させ、TOMLプラグインや1.0に必要なその他の重要なトピックを改善してください。

全くもって同じ意見です。 しかし、繰り返しになりますが、1.0がリリースされた後、重大な変更を追加することはかなりの期間非常に困難になるため、それを考慮する必要があります。

私にとって、この議論の結論は、ストレージプラグインを簡単に作成できるようにするためのライブラリが確実に必要であるということです。

👍

バイナリを除いて見られる

IMO、バイナリ値の場合は大きく異なります。 これは、他の多くの（ rgbcolor 、 macaddr 、 ipaddrなど）と同様に、1：1のキー値変換であるため、プラグインは実際にはここに適しています。 ただし、前述したように、一度に1つのキーのみを処理する新しいプラグインAPIは改善される可能性があります。 ただし、正しく実行すれば重大な変更にはならないため、1.0以降は簡単に追加できます。

ほとんど->しなければなりませんか？

はい、私はそれを同じように見ています：1.0がリリースされた後にこの変更が行われることは非現実的であり（1.0の全体的な目的は、他の人がそれに頼ることができるようにそのような決定を凍結することです）、前にそのような改善があるといいでしょう。 しかし、言ったように、私たちは本当に重要なことを成し遂げることに集中する必要があり、現在の人力では勝てない素敵な戦いでエネルギーを失わないようにする必要があります。