Libelektra: 유형용 라이브러리

제안을 기반으로 라이브러리를 구성하는 이례적인 방법이어야 한다고 생각합니다. 플러그인 간에 공통 기능을 추출하고 이를 라이브러리로 만드는 것이 훨씬 더 합리적입니다. @bauhaus93 의 TOML 플러그인에는 라이브러리(예: 주석 처리 코드)에 넣어야 하는 많은 양의 코드가 있습니다.

오해하지 마세요. @bauhaus93에 대한 좋은 정보입니다. 그리고 동일한 기능을 필요로 하는 두 번째 플러그인이 있다면 반드시 라이브러리에 넣어야 합니다. 그러나 라이브러리를 만드는 것은 플러그인 고유의 코드를 갖는 것보다 훨씬 더 많은 노력을 요하며 실제로 최소한 두 명의 고객이 있는 경우에만 노력해야 합니다.

@bauhaus93 유형 라이브러리가 있는 경우 즉각적인 이점이 없는 경우(예: 다른 플러그인과 함께 재사용) 문제를 종료하십시오.

동일한 기능을 필요로 하는 두 번째 플러그인이 있다면 반드시 라이브러리에 넣어야 합니다.

두 번째 플러그인의 개발자가 첫 번째 플러그인을 찾을 위치와 모든 것을 깨뜨리지 않고 코드를 추출하는 방법을 알고 있는 한 좋은 전략입니다. 안타깝게도 그렇지 않은 경우가 많습니다. 특히 첫 번째 플러그인은 라이브러리를 사용할 수 있도록 광범위하게 변경해야 하는 경우가 많기 때문입니다.

또한 일부 작업이 이미 완료되었기 때문에 라이브러리를 갖는 것은 실제로 누군가가 새 저장소 플러그인을 작성하도록 권장할 수 있습니다.

그러나 나는 이것을 low priority 로 태그를 붙

유형의 경우 10진수가 아닌 정수(2진수/8진수/16진수) 또는 날짜 시간(TOML은 RFC 3339 날짜 시간 사용)의 유효성 검사/변환을 제외하고 재사용 가능성에 대해 확신이 없습니다.
유형과 관계없이 작성할 KeySets 준비에서 재사용 가능성이 있습니다(예: array 메타키를 업데이트/추가하는 함수, 유효하지 않은 배열의 array 메타키 제거 또는 누락된 comment/#X 완전 삭제)

아직 눈치채지 못했을 수도 있지만 유형 플러그인이 하는 부울 정규화에 문제가 있을 수도 있습니다. 대부분의 형식이 true / false 사용하지만 Elektra는 1 / 0 사용하기 때문에 이것은 아마도 가장 많이 재사용되는 코드일 것입니다. yamlcpp 특수 코드를 추가해야 부울이 정수로 변환되거나 그 반대로 변환되지 않도록(또는 해당 라인을 따라) 생각합니다.

아, 잊어버렸습니다. TOML 플러그인도 이 값을 정규화해야 합니다.

문제는 값을 정규화해야 한다는 것만이 아닙니다. kdbSet 단계에서 toml 플러그인보다 먼저 실행되기 때문에 type 플러그인이 무엇을 하는지 정확히 알아야 합니다. 우리가 그것을 구현했는지 확실하지 않지만 type 플러그인이 1 / 0 또는 true /만 생성하는지 확인해야 합니다. false kdbSet 단계의 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 플러그인 수신 1 에서 kdbGet (있을 수에서 toml ),하지만 리턴 t 에서 kdbSet . 이것은 true = 0 및 false = 1 를 정의하는 사용자에게까지 갈 수 있어 toml 플러그인을 완전히 혼동할 수 있습니다. (나는 모든 부울이 kdbSet 마다 뒤집힐 것이라고 생각합니다)

이 엄청나게 복잡한 상호 작용 때문에 type 플러그인은 유형이 없는 저장 형식용이어야 하고 유형이 있는 저장 형식은 type 의 사용을 명시적으로 금지해야 한다고 생각합니다. 그러나 이를 가능하게 하려면 스토리지 플러그인, 즉 유형 라이브러리 내에서 유형을 지원하는 쉬운 방법이 필요합니다.

toml 플러그인은 16진수도 처리하므로 hexnumber 플러그인 사용을 명시적으로 허용하지 않을 수도 있습니다. (이 경우 문제가 발생할 가능성이 적다고 생각하지만)

또한 일부 작업이 이미 완료되었기 때문에 라이브러리를 갖는 것은 실제로 누군가가 새 저장소 플러그인을 작성하도록 권장할 수 있습니다.

대부분의 사용자는 아마도 문법만 작성하기를 원할 것이고 나머지는 마법처럼 저절로 일어나야 합니다. @bauhaus93 의 TOML 플러그인이 실제로 이 목표를 얼마나 달성했는지 궁금합니다. TOML 플러그인의 코드 기반으로 non-TOML 플러그인을 만드는 것은 흥미로울 것입니다. 그러나 유형 라이브러리만으로는 "저장 플러그인 작성"이라는 큰 작업에 지나치게 유용하기 때문에 전문화되어 있는 것 같습니다.

유형의 경우 10진수가 아닌 정수(2진수/8진수/16진수) 또는 날짜 시간(TOML은 RFC 3339 날짜 시간 사용)의 유효성 검사/변환을 제외하고 재사용 가능성에 대해 확신이 없습니다.

날짜/시간은 유효성 검사를 위해서만 Elektra에 존재했지만 RFC2822만 지원되었습니다. 날짜 플러그인은 파서를 재사용하여 RFC 3339를 검증할 수 있지만 저는 이것을 매우 낮은 우선순위로 간주합니다.

조금 더 흥미로운 것은 (TOML) 날짜가 있는 키의 keyGetDateTime(Key *k, struct tm *tm) 와 같은 것입니다.

유형과 관계없이 작성할 KeySets 준비에서 재사용 가능성이 있습니다(예: 배열 메타키를 업데이트/추가하는 함수, 유효하지 않은 배열의 배열 메타키를 제거하거나 누락된 주석/#X 메타키 데이터를 완료하는 기능).

예, 흥미로울 수 있습니다. 그러나 훨씬 더 매력적인 것은 문법과 터치 코드를 가능한 한 적게 직접 수정할 수 있다는 것입니다.

아직 눈치채지 못했을 수도 있지만 유형 플러그인이 하는 부울 정규화에 문제가 있을 수도 있습니다.

누락된 것은 doc/tutorials/storage-plugins.md의 일부 자습서/설명으로, 저장소 플러그인이 실제로 의존해야 하는 플러그인에 대한 최신 보기를 제공합니다. #2330은 "바이너리"가 필요할 수 있고 여전히 기본 스토리지로 적합한지 표시합니다.

또한 kdbSet 단계에서 toml 플러그인보다 먼저 실행되기 때문에 type 플러그인이 무엇을 하는지 정확히 알아야 합니다.

아마도 스토리지 플러그인은 유형 플러그인 사용을 중지하고 단순히 자체적으로 정규화를 수행해야 합니다(형식이 true/false에서 Elektra 등의 1/0까지). @bauhaus93 유형 플러그인의 다른 어떤 기능을 사용하십니까?

이것은 사용자가 true = 0 및 false = 1로 정의하여 toml 플러그인을 완전히 혼란스럽게 할 수 있습니다.

유형 플러그인의 기능을 줄이는 것이 좋습니다. 만약 있다면, 일부 추가적인 참/거짓 값은 사용자가 정의할 수 있어야 합니다(이전에는 분명히 참/거짓 값이 아니었음).

toml 플러그인은 16진수도 처리하므로 hexnumber 플러그인 사용을 명시적으로 허용하지 않을 수도 있습니다. (이 경우 문제가 발생할 가능성이 적다고 생각하지만)

플러그인이 함께 작동하지 않는다고 표현할 방법이 없습니다(이러한 기능이 있으면 마운트가 훨씬 복잡해집니다. 또한 어떤 플러그인이 어떤 플러그인과 작동하는지 테이블을 유지 관리하는 것도 너무 많은 작업이 될 것입니다.). 그러나 TOML 플러그인이 이미 이 기능과 그 이상(예: 이진수)을 가지고 있기 때문에 아마 아무도 그것들을 함께 사용할 생각을 하지 않을 것입니다.

대부분의 사용자는 아마도 문법만 작성하기를 원할 것이고 나머지는 마법처럼 저절로 일어나야 합니다.

그것이 가능하기에는 너무 마법 같은 것 같습니다. 수정된 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 완벽하고 손실 없이 왕복하도록 설계되었으며(플로트 문자열로 시작하더라도 상관없음) 고급 API에서도 사용됩니다. 따라서 toml 가 elektra*ToString 키를 생성하면 상위 수준 API에서 확실히 올바르게 읽을 수 있고 toml 는 highlevel API로 생성된 모든 것을 확실히 올바르게 읽을 수 있습니다. elektraKeyTo* .

저장소 플러그인이 실제로 의존해야 하는 플러그인에 대한 최신 보기.

IMO, 스토리지 플러그인은 다른 플러그인에 절대 _의존_해서는 안됩니다. 저장소 플러그인은 다른 플러그인으로 향상될 수 있지만 이상적으로는 독립 실행형으로 작동해야 합니다.

바이너리 키를 다루더라도 스토리지/타입 라이브러리로 더 잘 해결될 것입니다. 다시 말하지만 오류 메시지 등에 대한 일부 기준 표준을 보장합니다. 또한 필요하지 않은 형식에 대해 binary 플러그인 사용을 방지합니다. binary quickdump 와 결합하면 작동하지만 속도와 저장 공간 모두에 좋지 않습니다.

아마도 스토리지 플러그인은 유형 플러그인 사용을 중단하고 단순히 자체적으로 정규화를 수행해야 합니다.

그래서 도서관을 제안했습니다. 플러그인이 수행해야 하는 작업에 대한 비공식적인 설명(또는 공식 사양)을 제공하는 것보다 작업을 수행하는 라이브러리를 제공하는 것이 훨씬 좋습니다. 특히 사양이 시간이 지남에 따라 변경될 수 있는 경우.

유형 플러그인의 기능을 줄이는 것이 좋습니다.

이미 구현된 기능을 제거하는 이유는 무엇입니까? 원래는 boolean 플러그인을 따로 만들 생각이었는데 플러그인 순서 등으로 문제가 생기기도 했습니다.

만약 있다면, 일부 추가적인 참/거짓 값은 사용자가 정의할 수 있어야 합니다(이전에는 분명히 참/거짓 값이 아니었음).

정말 그럴 필요가 없습니다. 둘 이상의 플러그인이 부울 값이 무엇인지 정의하는 경우에만 문제가 있습니다.

true = 0 및 false = 1 도 완전히 괜찮습니다. Elektra 자체는 " 1 가 유일한 true 값이고 0 가 유일한 false 값"이므로 부울을 벌금으로 지정합니다.

플러그인이 함께 작동하지 않는다고 표현할 방법이 없습니다(이러한 기능이 있으면 마운트가 훨씬 복잡해집니다. 또한 어떤 플러그인이 어떤 플러그인과 작동하는지 테이블을 유지 관리하는 것도 너무 많은 작업이 될 것입니다.).

나는 동의하지 않는다. 물론 완전한 목록은 불가능하지만(결국 타사 플러그인도 있음) 솔루션은 간단합니다. 플러그인이 스스로 점검하도록 하십시오. elektra<Plugin>Get 또는 kdb mount 동안 호출되는 다른 함수에서.

부울 외에도 TOML 플러그인은 읽을 때 string, double 및 (unsigned_)long_long 유형도 설정합니다.

@kodebach 에 동의합니다. type 플러그인은 상호 작용의 어려움 때문에 내장형 시스템이 없는 플러그인에서만 사용해야 합니다.
예. TOML 플러그인은 10진수가 아닌 값에서도 읽을 때 정수에 대한 type 메타키를 설정합니다(10진수로 변환하는 동안 10진수가 아닌 표현은 origvalue ). 그러나 kdb set 로 입력된 값을 변경하려는 경우(및 이진/8진수/16진수 값으로 변경) 직접 변경할 수 없습니다(키 값 설정). 왜냐하면 type 플러그인 유형 검사가 성공하지 못했습니다. 대신 origvalue 메타키를 변경해야 합니다. (새 값을 설정하기 전에 type 메타 키를 삭제하면 읽을 때 메타 키가 재설정되므로 작동하지 않습니다.)

문제는 값을 정규화해야 한다는 것만이 아닙니다. 또한 kdbSet 단계에서 toml 플러그인보다 먼저 실행되기 때문에 type 플러그인이 무엇을 하는지 정확히 알아야 합니다. 구현했는지 확실하지 않지만 사용자가 제공한 구성에 관계없이 유형 플러그인이 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이 완료되면). 플러그인이 아름다운 오류 메시지와 함께 확인 및 실패만 하는 경우 상호 작용이 거의 없습니다.

libase의 변환 부분에 대한 작업처럼 들립니다.

예, 아마도 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" 및 "true" 값만 true로 간주하고 나머지는 false로 간주합니다.

아마도 우리는 "0" 또는 "1"이 아닌 모든 것에 대해 더 엄격하고 실패해야 합니다. TOML 파일 자체에서 "true"와 "false"만 허용하고 다른 것은 허용하지 않습니까?

그러나 유형 플러그인 없이도 모든 것이 자체적으로 수행됩니까? 유형 플러그인은 무엇에 사용됩니까?

예, 자체적으로 수행하며 렉싱 중에 다양한 유형이 일치합니다. 그러나 소수/이중 값이 long_long / double 초과/언더플로인지 확인하지 않으므로 type 플러그인에서 수행한다고 생각합니다.

아마도 우리는 "0" 또는 "1"이 아닌 모든 것에 대해 더 엄격하고 실패해야 합니다. TOML 파일 자체에서 "true"와 "false"만 허용하고 다른 것은 허용하지 않습니까?

예, 더 엄격하게 할 수 있습니다. 파일 자체에서 true 또는 false 부울로 쓰거나 읽습니다.

다른 모든 기능에 대해 이것이 제 결론이기도 합니다.

이 경우 type 라이브러리가 필요합니다. 그렇지 않으면 유형이 있는 형식에 대한 저장소 플러그인이 유형 항목을 다시 구현해야 합니다(다른 플러그인에 의존하는 것은 불가능하기 때문에).

유효한 가능성이 엄청나게 많다면 튜토리얼/설명이 더 나을 수 있습니다.

그러나 이 경우 별도의 플러그인도 솔루션이 아닙니다. 두 플러그인 모두에서 고려해야 할 수많은 가능한 상호 작용도 있기 때문입니다.

그런 코드가 이미 어딘가에 존재합니까?

AFAIK 그것은 플러그인이 마운트 된 다른 플러그인을 감지 할 수 있는지조차 확신하지 못합니다.

그러나 유형 플러그인 없이도 모든 것이 자체적으로 수행됩니까? 유형 플러그인은 무엇에 사용됩니까?

예, 자체적으로 수행하며 렉싱 중에 다양한 유형이 일치합니다. 그러나 소수점/이중 값이 long_long / double 초과/언더플로인지 확인하지 않으므로 type 플러그인에서 수행한다고 생각합니다.

예 type 또한 범위 검사를 수행하고 float / double 및 enum 와 같은 기타 항목의 유효성을 검사합니다.

아마도 우리는 "0" 또는 "1"이 아닌 모든 것에 대해 더 엄격하고 실패해야 합니다. TOML 파일 자체에서 "true"와 "false"만 허용하고 다른 것은 허용하지 않습니까?

그리고 그것은 유형 또는 보다 구체적으로 변환/정규화에 대한 매우 복잡하고 복잡한 경우 중 하나입니다.

하자가 가정 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가 적을수록 더 좋다는 데 동의합니다. 플러그인의 경우 플러그인 또는 그 일부가 실험적이라고 쉽게 말할 수 있습니다.

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 값이 long_long/double을 오버/언더플로하는지 여부는 확인하지 않으므로 typeplugin에서 수행한다고 생각합니다.

좋습니다. 기본적으로 확인용으로만 사용합니다.

그러나이 경우 별도의 플러그인도 솔루션이 아닙니다.

아니요, 불행히도 별도의 플러그인은 솔루션이 아닙니다. 우리는 거기에서 실패했습니다. 현재 솔루션은 모든 스토리지 플러그인이 doc/tutorials/storage-plugins.md를 기반으로 모든 것(바이너리 처리 제외)을 구현한다는 것입니다.

그러나 사용자는 아마도 kdb set /some/key/mounted/with/toml true가 작동할 것이라고 예상할 것입니다.

아니요, 사용자는 이를 기대해서는 안 됩니다. Elektra에서 1/0은 참/거짓입니다. 저장소 플러그인만이 이것을 다른 것에 매핑할 수 있습니다.

근거: 최소한 사양 수준에서는 1/0만 작동하므로 다른 곳에서 true/false를 작동시키는 것은 혼란스러울 뿐입니다(스토리지 플러그인 제외).

이것은 저장소 플러그인이 다른 플러그인을 사용하지 않고 저장소 형식이 지원하는 모든 유형과 관련 변환을 처리할 수 있어야 함을 보여줍니다.

그래, 난 동의.

단순히 코드를 삭제하는 것이 올바른 해결책은 아니라고 생각하지만 그것은 정당합니다.

물론 우리는 "올바른" 코드를 삭제해야 합니다. 기대를 충족시키지 않고 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이 (다소) 이 점에 동의하는 것 같습니다.

스토리지 플러그인이 이를 처리해야 한다는 데 동의합니다(이스케이프가 작동하지 않고 올바른 이스케이프가 스토리지 플러그인의 주요 작업 중 하나이기 때문에 라이브러리가 있지만 "directoryvalue" 플러그인이 아닐 수도 있음).

좋습니다. 기본적으로 확인용으로만 사용합니다.

" toml 플러그인은 type 플러그인을 사용합니다"라는 문구에 동의하지 않습니다. 현재 버전에서는 type 만 권장합니다.

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

type 가 needs 로 선언되더라도 나는 그것을 "using"이라고 부르지 않을 것입니다. toml 실제로 type 대한 직접적인 제어 권한이 없습니다. 이것이 내가 toml 가 type 에 의존한다고 말한 이유입니다. type 가 특정 방식으로 특정 작업을 수행할 것으로 예상하지만 그렇지 않으면 아무 것도 할 수 없습니다.

#666을 재작업하고 마운트하는 동안 경고를 출력하면 더 잘 작동할 수 있습니다.

나는 동의한다. 특별한 "이 마운트 포인트가 실험적 플러그인을 사용함을 인정합니다" 키가 설정되지 않는 한 모든 kdbGet 에도 마찬가지입니다.

base64가 바이너리 데이터를 인코딩하는 유일한 방법은 아닙니다.

이것은 실제로 binary 플러그인에 대한 인수입니다. 플러그인이 한 번에 하나의 키를 작동할 수 있는 인터페이스를 여전히 원하지만 이것은 메모리를 어느 정도 절약하고 성능도 절약할 수 있습니다. (하지만 그건 다른 문제)

많은 형식에서 매우 일반적입니다.

예가 있습니까?

그리고 사양을 확장할 때 매우 유용할 수 있습니다(값이 있는 키에서 하위 키 생성).

사실이지만 그 경우에는 (최종 사용자 POV에서) "둘 중 하나 또는 둘 중 하나" 솔루션을 권장합니다. 단일 값과 함께 이전 키를 사용하거나 하위 키와 함께 새 버전을 사용합니다. 그렇지 않으면 구성이 혼란스러울 수 있습니다.

분명히 말해서, 값이 있는 리프가 아닌 키를 사용해서는 안 된다고 생각하지만 가능하면 피해야 하며 선호되는 솔루션은 거의 없습니다.

하지만 이스케이프가 작동하지 않기 때문에 "directoryvalue" 플러그인을 사용하면 안 됩니다.

#3256에서 나는 탈출 문제를 해결하기 위해 메타데이터를 사용할 것을 제안했습니다. 또한 이스케이프 문제( directoryvalue 뿐만 아니라 모든 사용 사례에 대해)와 다른 몇 가지 문제를 해결할 수 있는 #3223의 아이디어가 있습니다. (매우 형식적인) 제안 도 참조하십시오. 나는 여전히 이러한 변화에 매우 찬성하기 때문에 오늘이나 내일 그 문서에 평범한 영어 설명을 추가할 것입니다.

@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 대신 BACKUP_ENABLE 사용합니다.

또한 이스케이프 문제( directoryvalue 뿐만 아니라 모든 사용 사례에 대해)와 다른 몇 가지를 해결할 수 있는 #3223의 아이디어가 있습니다.

이제 #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 이므로 실제 구현은 여전히 ​​작성되어야 하고 테스트 및 아마도 스토리지 플러그인을 업데이트해야 합니다.

저에게 가장 큰 문제는 스토리지 플러그인입니다. 코어 및 테스트에 대한 업데이트와 하나의 스토리지 플러그인을 구현할 수 있습니다. 그러나 모든 스토리지 플러그인에 대한 코드를 연구하고 모든 형식의 모든 복잡성을 파악할 필요가 없다면 선호합니다.

ㅋ 제안서의 첫 번째 부분은 실제로 키 이름이 작동하는 방식에 대한 훌륭한 자습서입니다. 이것을 튜토리얼로 가지고 있으면 놀랍습니다.

그래서 이렇게 썼습니다. 내 계획은 이 제안의 일부를 #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/12)에 필요한 기타 중요한 주제를 개선하겠습니다. github.com/ElektraInitiative/libelektra/milestone/14). 이것이 좋아 보이면 우리가 달성할 수 있는 다른 아이디어를 볼 수 있습니다.

나에게 이 토론의 결론은 플러그인 접근 방식이 작동하지 않았기 때문에 스토리지 플러그인을 더 쉽게 작성할 수 있도록 라이브러리가 확실히 필요하다는 것입니다(바이너리가 표시되는 경우 제외). 이 결론은 스토리지 플러그인 튜토리얼에 있어야 합니다.
@bauhaus93 스토리지 플러그인 튜토리얼을 계속

하나를 제외한 모든 스토리지 플러그인을 파괴하는 PR은 병합할 수 없습니다.

나는 아무도 그런 PR을 병합할 것이라고 기대하지 않았습니다... 나는 단지 다른 사람들이 스토리지 플러그인 업데이트에 도움을 줄 수 있다면 좋을 것이라고 말했습니다. 이상적으로는 플러그인의 원래 작성자입니다. #3491 이후에는 더 복잡한 저장소 플러그인 중 일부가 제거되므로 전체 작업이 더 쉬워집니다.

그리고 스토리지 플러그인은 이 PR에서 많은 이점을 얻지 못합니다. 실제로 지금 구문 분석할 수 있는 파일에 구문 오류를 갑자기 생성한다는 점에서 "더 나빠집니다".

이런 경우가 있어서는 안 됩니다. 제안 말미에 부분적인 설명도 있습니다. 그것이로 번역 될 수 없기 때문에 AFAIK는 저장 플러그인 파일을 거부해야하는 경우,이 안 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 키 값 변환이므로 플러그인이 실제로 여기에 적합합니다. 그러나 내가 말했듯이 한 번에 하나의 키만 처리하는 새로운 플러그인 API가 개선될 수 있습니다. 그러나 올바르게 수행되면 주요 변경 사항이 아니기 때문에 1.0 이후에 쉽게 추가할 수 있습니다.

대부분 -> 해야 합니까?

예, 같은 방식으로 봅니다. 1.0이 나오면 이 변경이 발생한다는 것은 비현실적이며(1.0의 전체 목적은 그러한 결정을 동결하여 다른 사람들이 그것에 의존할 수 있도록 하는 것입니다) 그러한 개선이 이전에 있었으면 좋았을 것입니다. . 그러나 말했듯이 우리는 정말로 중요한 일을 끝내는 데 집중해야 하며 현재의 인력으로 이길 수 없는 좋은 전투에서 에너지를 잃지 않아야 합니다.