Libelektra: Biblioteca para tipos

Acho que deveria ser a forma excepcional de formar bibliotecas com base em propostas. Faz muito mais sentido extrair funcionalidades comuns entre plug-ins e fazer disso uma biblioteca. O plugin TOML de @ bauhaus93 tem toneladas de código que faria muito sentido ser colocado em uma biblioteca (por exemplo, o código de tratamento de comentários).

Não me interpretem mal, é uma boa entrada para @ bauhaus93. E se houver um segundo plugin que precisa da mesma funcionalidade, definitivamente devemos colocá-lo em uma biblioteca. Mas criar bibliotecas exige muito mais esforço do que ter código específico de plug-in e o esforço só deve ser feito se houver pelo menos dois clientes.

@ bauhaus93 se você não vê um benefício imediato em ter uma biblioteca de tipos (por exemplo, reutilizar com outro plug-in), feche o problema.

se houver um segundo plugin que precisa da mesma funcionalidade, definitivamente devemos colocá-lo em uma biblioteca

Desde que o desenvolvedor do segundo plugin saiba onde encontrar o primeiro plugin e como extrair o código dele sem quebrar tudo que é uma boa estratégia sim. Infelizmente, nem sempre é esse o caso. Especialmente, já que muitas vezes o primeiro plugin tem que ser alterado extensivamente para que possa usar uma biblioteca.

Ter a biblioteca também pode encorajar alguém a escrever um novo plugin de armazenamento, uma vez que parte do trabalho já está feito.

Mas eu marquei isso como low priority , exatamente porque eu sabia que é muito trabalhoso e provavelmente não há ninguém que queira fazer isso.

Para tipos, não tenho certeza sobre a reutilização, exceto talvez para a validação / conversão de inteiros não decimais (binários / octal / hexadecimal) ou datetimes (TOML usa datetimes RFC 3339).
Não relacionado aos tipos, vejo alguma capacidade de reutilização na preparação de KeySets a serem gravados (por exemplo, funções que atualizam / adicionam array metakeys, removem array metakeys de arrays inválidos ou completam comment/#X ausentes

Você pode não ter notado ainda, mas também pode haver problemas com a normalização de booleanos que o plug-in de tipo faz. Este é provavelmente o código mais reutilizado, já que a maioria dos formatos usará true / false mas Elektra usa 1 / 0 . Acho que yamlcpp teve que adicionar algum código especial, para que os booleanos não sejam convertidos em inteiros ou vice-versa (ou algo parecido).

Ah sim, esqueci disso, o plugin TOML também tem que normalizar esses valores.

O problema não é só que você tem que normalizar os valores. Você também tem que saber exatamente o que o type plugin faz, uma vez que é executado antes do toml plug-in no kdbSet fase. Não tenho certeza se já o implementamos, mas você também deve garantir que o plugin type produza apenas 1 / 0 ou true / false na fase kdbSet , independentemente da configuração fornecida pelo usuário. Caso contrário, toml teria que ser capaz de analisar a configuração do plugin type , uma vez que o usuário pode definir valores verdadeiros e falsos personalizados (consulte o caso de teste abaixo)

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

A parte interessante é:

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

O plug-in type recebe um 1 em kdbGet (pode ser de toml ), mas retorna um t em kdbSet . Isso poderia ir tão longe quanto um usuário definir aqueles true = 0 e false = 1 que confundiria totalmente o plugin toml . (Acho que todos os booleanos virariam a cada kdbSet )

Essa interação extremamente complexa é porque eu acho que o plug-in type deve ser para formatos de armazenamento que não têm tipos e aqueles que os têm devem proibir explicitamente o uso de type . Mas para tornar isso viável, precisamos de uma maneira fácil de oferecer suporte a tipos dentro de plug-ins de armazenamento, ou seja, uma biblioteca de tipos.

Como o plug-in toml também lida com números hexadecimais, ele provavelmente também deve proibir explicitamente o uso do plug-in hexnumber . (embora, nesse caso, haja menos potencial para problemas, eu acho)

Ter a biblioteca também pode encorajar alguém a escrever um novo plugin de armazenamento, uma vez que parte do trabalho já está feito.

A maioria dos usuários provavelmente deseja apenas escrever a gramática e o resto deve acontecer por si mesmo como um passe de mágica. Eu me pergunto até que ponto o plugin TOML de @ bauhaus93 realmente atingiu esse objetivo. Seria interessante fazer um plugin não-TOML com o código-base do plugin TOML. Uma biblioteca de tipos sozinha, entretanto, parece-me muito especializada para ser excessivamente útil para a grande tarefa de "escrever um plugin de armazenamento".

Para tipos, não tenho certeza sobre a reutilização, exceto talvez para a validação / conversão de inteiros não decimais (binários / octal / hexadecimal) ou datetimes (TOML usa datetimes RFC 3339).

Data / horas existiam no Elektra apenas para validação, mas apenas RFC2822 era suportado. O plugin de data poderia reutilizar seu analisador para validar RFC 3339, mas eu consideraria isso como uma prioridade muito baixa.

O que seria um pouco mais emocionante é algo como keyGetDateTime(Key *k, struct tm *tm) de uma chave com uma data (TOML).

Não relacionado a tipos, vejo alguma capacidade de reutilização na preparação de KeySets a serem escritos (por exemplo, funções que atualizam / adicionam metachaves de array, removem metachaves de array de arrays inválidos ou completam comentários ausentes / # dados de metakey X).

Sim, isso pode ser interessante. Mas ainda mais fascinante seria a possibilidade de modificar diretamente a gramática e tocar o código o mínimo possível: wink:

Você pode não ter notado ainda, mas também pode haver problemas com a normalização de booleanos que o plug-in de tipo faz.

O que está faltando é algum tutorial / explicação em doc / tutorials / storage-plugins.md que fornece uma visão atualizada de quais plug-ins um plug-in de armazenamento realmente deve confiar. # 2330 mostrará se "binário" pode ser necessário e ainda é adequado como armazenamento padrão.

Você também precisa saber exatamente o que o plug-in de tipo faz, uma vez que é executado antes do plug-in toml na fase kdbSet.

Provavelmente, os plug-ins de armazenamento deveriam parar de usar o plug-in de tipo e simplesmente fazer sua normalização simplesmente (de tudo que é verdadeiro / falso em seu formato para 1/0 no Elektra e assim por diante). @ bauhaus93 que outra funcionalidade do plugin de tipo você usa?

Isso poderia ir tão longe quanto um usuário definir true = 0 e false = 1, o que confundiria totalmente o plugin toml.

Eu seria a favor de reduzir a funcionalidade do plugin de tipo. Se houver alguma coisa, alguns valores verdadeiros / falsos adicionais devem ser definidos pelo usuário (que obviamente não eram valores verdadeiros / falsos antes).

Uma vez que o plug-in toml também lida com números hexadecimais, ele provavelmente também deve proibir explicitamente o uso do plug-in hexadecimal. (embora, nesse caso, haja menos potencial para problemas, eu acho)

Não há como expressar que os plug-ins não funcionam juntos (ter tal funcionalidade tornaria a montagem muito mais complicada. Também seria muito trabalhoso para nós manter uma tabela de qual plug-in funciona com qual plug-in.). Mas provavelmente ninguém terá a ideia de usá-los juntos, pois o plugin TOML já tem essa funcionalidade e muito mais (por exemplo, também números binários).

A maioria dos usuários provavelmente deseja apenas escrever a gramática e o resto deve acontecer por si mesmo como um passe de mágica.

Isso parece um pouco mágico demais para ser possível. Pode ser possível com um gerador de código personalizado baseado em uma gramática Yacc ou ANTLR modificada. Mas não acho que haja uma maneira de ter um código que crie KeySet s simplesmente a partir de uma gramática para formatos muito diferentes como JSON, XML, TOML e edn . Como @ 'sanssecours encontrado, também existem formatos como YAML que são muito difíceis de expressar em um formato de gramática padrão.

Uma biblioteca de tipos sozinha, entretanto, parece-me muito especializada para ser excessivamente útil para a grande tarefa de "escrever um plugin de armazenamento".

Claro que poderíamos estender a biblioteca em uma biblioteca geral storage que fornece mais funções auxiliares para plug-ins de armazenamento (por exemplo, lidar com stdin / stdout e canais para importação / exportação). O tipo de coisa então seria uma parte disso.

Eu também acho que você subestima o quão complicado esse tipo de coisa pode ser. Se tivéssemos uma biblioteca de tipos padrão, estender o sistema de tipos também seria mais fácil, por exemplo, para armazenar versões binárias pré-analisadas de inteiros além (para as versões de string para reduzir a sobrecarga de análise). Uma biblioteca storage também pode usar APIs internas (se necessário), uma vez que é mantida pelos desenvolvedores Elektra.

Outra, uma biblioteca de tipo padrão também garantiria mensagens de erro padrão para problemas de tipo. Portanto, haveria até uma vantagem para os usuários finais.

O que seria um pouco mais emocionante é algo como keyGetDateTime (Key * k, struct tm * tm)

Parece um trabalho para a parte de conversão de libease (as elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@ bauhaus93 as funções lá podem ser úteis para toml também. Eles são projetados de forma que, por exemplo, elektraKeyToFloat e elektraFloatToString ida e volta perfeitos e sem perdas (não importa se você comece com a flutuação de uma string) e também sejam usados ​​na API de alto nível. Portanto, se toml criar a chave com elektra*ToString ela pode definitivamente ser lida corretamente pela API de alto nível e toml pode definitivamente ler corretamente qualquer que seja a highlevel API produzida com elektraKeyTo* .

uma visão atualizada de quais plug-ins um plug-in de armazenamento realmente deve confiar.

IMO, um plugin de armazenamento nunca deve _confiar_ em qualquer outro plugin. Os plug-ins de armazenamento podem ser aprimorados por outros plug-ins, mas o ideal é que funcionem de forma autônoma.

Mesmo lidando com chaves binárias, seria melhor resolvido por uma biblioteca de armazenamento / tipo. Novamente, ele garante alguns padrões básicos para mensagens de erro, etc. Também evita o uso do plugin binary para formatos que não precisam dele. Embora binary combinado com, por exemplo, quickdump funcione, é ruim para velocidade e tamanho de armazenamento.

Provavelmente, os plug-ins de armazenamento devem parar de usar o plug-in de tipo e simplesmente fazer sua normalização por conta própria

Razão pela qual propus uma biblioteca. É muito melhor fornecer uma biblioteca que faça o trabalho do que apenas fornecer uma descrição informal (ou mesmo uma especificação formal) do que o plugin deve fazer. Especialmente se a especificação puder mudar com o tempo.

Eu seria a favor de reduzir a funcionalidade do plugin de tipo.

Por que retirar uma funcionalidade que já está implementada? Originalmente, a ideia era ter um plugin boolean separado, mas isso também causou problemas, por causa da ordem do plugin e coisas assim.

Se houver alguma coisa, alguns valores verdadeiros / falsos adicionais devem ser definidos pelo usuário (que obviamente não eram valores verdadeiros / falsos antes).

Não há realmente necessidade disso. Só há um problema, se mais de um plugin definir o que é um valor booleano.

Mesmo true = 0 e false = 1 estão totalmente bem. A própria Elektra define os booleanos como " 1 é o único valor verdadeiro e 0 é o único valor falso".

Não há como expressar que os plug-ins não funcionam juntos (ter tal funcionalidade tornaria a montagem muito mais complicada. Também seria muito trabalhoso para nós manter uma tabela de qual plug-in funciona com qual plug-in.).

Discordo. Obviamente, uma lista exaustiva seria impossível (afinal também existem plug-ins de terceiros), mas a solução é simples. Deixe os plug-ins fazerem a verificação sozinhos. Em elektra<Plugin>Get ou em outra função que é chamada durante kdb mount .

Além do booleano, o plugin TOML também define os tipos string, double e (unsigned_) long_long na leitura.

Concordo com @kodebach , que o plug-in type só deve ser usado por plug-ins sem um sistema de tipo embutido, devido a dificuldades de interação.
Por exemplo. o plugin TOML define a metachave type para inteiros na leitura também em valores não decimais (ao convertê-los em decimais, armazenando a representação não decimal em origvalue ). No entanto, se você quiser alterar esse valor digitado com kdb set (e fazer isso pelo valor binário / octal / hex), não poderá fazer isso diretamente (definindo o valor-chave), porque o type verificações de tipo de plug-in não seriam bem-sucedidas. Você teria que alterar a metakey origvalue . (Excluir a metachave type antes de definir um novo valor não funcionaria, pois a metachave será redefinida na leitura.)

O problema não é só que você tem que normalizar os valores. Você também precisa saber exatamente o que o plug-in de tipo faz, uma vez que é executado antes do plug-in toml na fase kdbSet. Não tenho certeza se já o implementamos, mas você também deve garantir que o plug-in de tipo produza apenas 1/0 ou verdadeiro / falso na fase kdbSet, independentemente da configuração fornecida pelo usuário. Caso contrário, toml teria que ser capaz de analisar a configuração do plug-in de tipo, uma vez que o usuário pode definir valores verdadeiros e falsos personalizados (consulte o caso de teste abaixo)

Sim, já me perguntei se / como posso verificar os valores booleanos definidos pelo usuário. Atualmente, ao escrever, o plugin TOML considera apenas os valores de "1" e "true" como verdadeiros, o resto seria visto como falso.

@kodebach escreveu:

Isso parece um pouco mágico demais para ser possível.

Com Augeas é possível (mas as árvores que você consegue não são tão desejáveis). Seria interessante o quão longe estamos com a solução TOML atual. Claro que você precisa escrever algum código de emissor, mas isso geralmente não é tão dramático.

JSON, XML

É a vantagem do Elektra que formatos tão diferentes podem ser implementados em tecnologias diferentes. Tentar implementar XML do zero provavelmente não é a melhor ideia. Se formatos como o INI pudessem ser incluídos, já seria incrível.

Mas é claro que a primeira e mais importante coisa é obter um bom plugin TOML: 1st_place_medal:

Outra, uma biblioteca de tipo padrão também garantiria mensagens de erro padrão para problemas de tipo.

A verificação pode ser feita facilmente em outros plugins (assim que o # 2963 estiver pronto). Se um plug-in apenas verifica e falha com uma bela mensagem de erro, há pouca / nenhuma interação.

Parece um trabalho para a parte de conversão do libease

Sim, provavelmente algumas das coisas do TOML poderiam ir para libease ou libmeta.

IMO, um plugin de armazenamento nunca deve depender de nenhum outro plugin.

Para binário, ainda não tenho certeza (já que provavelmente é algo que não é necessário para back-ends padrão), para todas as outras funcionalidades, essa também é minha conclusão. Mas essa conclusão ainda não é amplamente aceita (@sanssecours?) Nem documentada.

Razão pela qual propus uma biblioteca. É muito melhor fornecer uma biblioteca que faça o trabalho do que apenas fornecer uma descrição informal (ou mesmo uma especificação formal) do que o plugin deve fazer. Especialmente se a especificação puder mudar com o tempo.

Depende: se houver um grande número de possibilidades válidas, um tutorial / descrição pode ser melhor do que uma biblioteca complicada que de alguma forma tenta dar essa flexibilidade. E para serializações, há uma gama imensa de possibilidades válidas e muitas delas têm implementações triviais (por exemplo, simplesmente chamar elektraFormat com alguns parâmetros) até implementações complicadas (por exemplo, se eles suportam muitas representações de conveniência).

Por que retirar uma funcionalidade que já está implementada?

A Elektra está atualmente entrando em colapso com o peso de manter muito código. Cada linha de código inútil (no sentido de que ninguém a usa) da qual nos livramos torna o Elektra melhor.

Infelizmente, mesmo o código separado em plug-ins cria problemas: por exemplo, no servidor de compilação ou quando um usuário tenta usá-lo, há interações indesejadas / documentos ausentes / ...

Não podemos lançar tudo o que temos atualmente como 1.0, Elektra seria uma decepção então. Precisamos nos livrar de tudo o que não é necessário. Agradecemos cada limpeza que você pode fazer.

Essa é também a razão pela qual o TOML irá substituir o INI. # 3491

Deixe os plug-ins fazerem a verificação sozinhos.

Raramente era uma boa solução. Ele fica muito inconsistente e a ordem de adição de plug-ins pode produzir resultados diferentes. Esse código já existe em algum lugar?

@ bauhaus93 escreveu:

Além do booleano, o plugin TOML também define os tipos string, double e (unsigned_) long_long na leitura.

Mas tudo isso por si só, sem o plug-in de tipo? Qual é o tipo de plugin usado?

Em vez disso, você teria que alterar a metachave origvalue.

Sim, aqui ainda não temos uma solução legal (# 3056). keySetString remove origvalue, mas de alguma forma o comportamento ainda não é o que o usuário esperava.

Atualmente, ao escrever, o plugin TOML considera apenas os valores de "1" e "verdadeiro" como verdadeiros, o resto seria visto como falso.

Provavelmente deveríamos ser mais rígidos e falhar em tudo que não seja "0" ou "1". No próprio arquivo TOML, você também permite apenas "verdadeiro" e "falso" e nada mais?

Mas tudo isso por si só, sem o plug-in de tipo? Qual é o tipo de plugin usado?

Sim, ele faz isso sozinho, os diferentes tipos serão combinados durante a lexagem. No entanto, ele não verifica se os valores decimais / duplos excedem / diminuem long_long / double , então acho que isso é feito pelo plug-in type .

Provavelmente deveríamos ser mais rígidos e falhar em tudo que não seja "0" ou "1". No próprio arquivo TOML, você também permite apenas "verdadeiro" e "falso" e nada mais?

Sim, posso tornar isso mais rígido. No próprio arquivo, apenas true ou false é escrito / lido como booleano.

para todas as outras funcionalidades, esta também é minha conclusão.

Nesse caso, precisamos de uma biblioteca type . Caso contrário, qualquer plug-in de armazenamento para um formato com tipos teria reimplementado o material de tipo (já que depender de outro plug-in está fora de questão).

se houver um grande número de possibilidades válidas, um tutorial / descrição pode ser melhor

Mas, nesse caso, um plug-in separado também não é a solução, porque então também há um grande número de possíveis interações que precisam ser consideradas em ambos os plug-ins.

Esse código já existe em algum lugar?

AFAIK não. Eu nem tenho certeza se um plug-in pode detectar quais outros plug-ins estão montados.

Mas tudo isso por si só, sem o plug-in de tipo? Qual é o tipo de plugin usado?

Sim, ele faz isso sozinho, os diferentes tipos serão combinados durante a lexagem. No entanto, ele não verifica se os valores decimais / duplos estão acima / abaixo de long_long / double , então acho que isso é feito pelo plug-in type .

Sim type também faz verificação de intervalo, valida float / double e outras coisas como enum s.

Provavelmente deveríamos ser mais rígidos e falhar em tudo que não seja "0" ou "1". No próprio arquivo TOML, você também permite apenas "verdadeiro" e "falso" e nada mais?

E esse é exatamente um desses casos extremamente complexos e complicados para tipos ou, mais especificamente, conversão / normalização.

Vamos supor que toml só aceita true / false como entrada e só produz 0 / 1 em kdbGet e isso só aceita 0 / 1 e só produz true / false em kdbSet . Isso estaria de acordo com as especificações Elektra e TOML para booleanos. Mas um usuário provavelmente esperaria que kdb set /some/key/mounted/with/toml true funcionasse. No entanto, isso não acontece. Com a configuração correta para type ele pode funcionar, mas rapidamente se torna estranho. Por exemplo, e se a chave existisse antes. Então não há metakey type e o plugin type simplesmente o ignora, toml recebe true e reclama que true não é válido boleano...

Isso apenas mostra que um plug-in de armazenamento DEVE ser capaz de lidar com todos os tipos que o formato de armazenamento suporta e as conversões associadas SEM usar quaisquer outros plug-ins.

A Elektra está atualmente entrando em colapso com o peso de manter muito código. Cada linha de código inútil (no sentido de que ninguém a usa) da qual nos livramos torna o Elektra melhor.

Esse é um ponto justo, embora eu não ache que simplesmente excluir o código seja a solução certa. Pelo menos não quando se trata de plug-ins. No núcleo, concordo, quanto menos LOC, melhor. Para plug-ins, podemos facilmente dizer que o plug-in ou alguma parte dele é experimental.

IMO, um plugin de armazenamento nunca deve depender de nenhum outro plugin.

Mas essa conclusão ainda não é amplamente aceita (@sanssecours?) Nem documentada.

Pelo que eu sei, não há nenhum lugar na documentação que afirme que um plug-in de armazenamento não deve depender de outros plug-ins. Eu também não acho isso ótimo do ponto de vista da separação das preocupações. Escrever um bom plugin de armazenamento já dá bastante trabalho, na minha opinião. Exigir que um plugin de armazenamento cuide da conversão de tipo, chaves de diretório e dados binários (codificação Base64) não torna esse trabalho mais fácil.

Eu também não acho isso ótimo do ponto de vista da separação das preocupações. Escrever um bom plugin de armazenamento já dá bastante trabalho, na minha opinião.

Esse é o ponto da biblioteca auxiliar. Ele divide o código comum e, portanto, fornece (alguma) separação de interesses, além de tornar o desenvolvimento do plug-in mais fácil.

Em relação à preocupação de @ markus2330 de que desenvolver uma biblioteca de uso geral é mais difícil do que um plugin semelhante: Isso é factualmente errado, porque você poderia simplesmente fornecer uma versão ligeiramente modificada da função elektraTypeGet atual como uma biblioteca. As modificações são necessárias apenas porque precisamos substituir Plugin * handle por KeySet * config . Embora isso possa não resolver todos os problemas, pelo menos permite que o plug-in de armazenamento controle exatamente como e quando o tipo de coisa é feito.

Por exemplo, toml poderia ter um modo de fallback INI onde não usa o sistema de tipo TOML, mas em vez disso, adia para type e um modo TOML normal onde fornece elektraTypeGet com uma configuração muito precisa que garante que tudo esteja em conformidade com as especificações TOML.

Resumindo, uma biblioteca é simples e muito mais flexível do que um plug-in do ponto de vista do plug-in de armazenamento. Pelo menos com as possibilidades de configuração do plugin atual.

Exigir que um plugin de armazenamento cuide da conversão de tipo, chaves de diretório e dados binários (codificação Base64) não torna esse trabalho mais fácil.

Vamos decompô-lo:

• Dados binários: não há realmente nenhum esforço envolvido em fazer algo como:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  Um plug-in separado também funcionaria, desde que o plug-in de armazenamento possa garantir que o outro plug-in seja montado em todas as circunstâncias e possa simplesmente assumir que não há chaves binárias. Se o plug-in ainda precisar chamar keyIsBinary e gerar um erro, não haverá benefício para esta solução. Eu também não gosto que um plugin binário separado tenha que converter todo o KeySet uma vez, porque então todas as chaves Base64 gastam um pouco de memória.
• Chaves de diretório: primeiro, essas chaves não-folha com valores são estranhas em quase todas as circunstâncias e, na verdade, devemos recomendar que sejam evitadas. Quando se trata de lidar com essas chaves, conforme declarado em # 3256, acho que uma biblioteca é muito mais adequada para este caso. Há muitos motivos, incluindo sobrecarga de memória e processamento, complicando desnecessariamente as configurações e a flexibilidade do ponto de montagem. Parece que @ markus2330 (um pouco) concorda comigo neste ponto.
• Tipos: qualquer plugin de armazenamento para um formato que tenha um sistema de tipo nativo terá que fazer pelo menos algum trabalho para os tipos. Isso pode variar de fazer a conversão completa desde o início até chamar alguma biblioteca e configurar outro plug-in. Nunca será possível que tudo simplesmente funcione. Mesmo se você tiver uma especificação formal muito detalhada para tipos, de forma que nenhuma configuração direta do plug-in de tipo seja necessária, o plug-in de armazenamento terá que implementar essa especificação de uma forma ou de outra.

No entanto, ele não verifica se os valores decimais / double over- / underflow long_long / double, então acho que isso é feito pelo typeplugin.

Ok, basicamente você só o usa para verificar.

Mas, nesse caso, um plugin separado também não é a solução

Não, os plug-ins separados infelizmente não são a solução. Nós falhamos lá. A solução atual é que cada plug-in de armazenamento implementa tudo (exceto o manuseio de binários) com base em doc / tutorials / storage-plugins.md

Mas um usuário provavelmente esperaria que kdb set / some / key / installed / with / toml true funcionasse.

Não, um usuário não deve esperar isso. Em Elektra 1/0 são verdadeiro / falso. Apenas plug-ins de armazenamento podem mapear isso para outra coisa.

Justificativa: como pelo menos no nível de especificação apenas 1/0 está funcionando, seria apenas confuso fazer verdadeiro / falso funcionando em qualquer outro lugar (com exceção dos plug-ins de armazenamento).

Isso apenas mostra que um plug-in de armazenamento DEVE ser capaz de lidar com todos os tipos que o formato de armazenamento suporta e as conversões associadas SEM usar quaisquer outros plug-ins.

Sim eu concordo.

Esse é um ponto justo, embora eu não ache que simplesmente excluir o código seja a solução certa.

É claro que precisamos deletar o código "certo": aquele que lhe dá expectativas sem cumpri-lo ou introduzir problemas com outras partes da Elektra. E algumas funcionalidades do plugin de tipo parecem criar problemas junto com outras partes do Elektra.

Pelo menos não quando se trata de plug-ins. No núcleo, concordo, quanto menos LOC, melhor. Para plug-ins, podemos facilmente dizer que o plug-in ou alguma parte dele é experimental.

Infelizmente, isso não funciona (ainda *). As pessoas não julgam o status dos plug-ins corretamente, por exemplo, recentemente, veja: # 3472 onde o plug-in INI sem manutenção e sem bugs, e ainda pior, o plug-in xmltool antigo desencorajado, funcionou perfeitamente.

• Pode funcionar melhor se eu retrabalhar o nº 666 e emitirmos avisos durante a montagem.

Exigir que um plugin de armazenamento cuide da conversão de tipo, chaves de diretório e dados binários (codificação Base64) não torna esse trabalho mais fácil.

@sanssecours como os plug-ins YAML lidam com a conversão de tipo?

Isso é factualmente errado

Veremos quando estiver pronto: stick_out_tongue_winking_eye:

Resumindo, uma biblioteca é simples e muito mais flexível do que um plug-in do ponto de vista do plug-in de armazenamento. Pelo menos com as possibilidades de configuração do plugin atual.

Ninguém discutiu sobre isso. Mas a flexibilidade às vezes tem um preço alto.

Não há realmente nenhum esforço envolvido em fazer algo como

base64 não é a única maneira de codificar dados binários. Para padrões em que base64 é necessária, pode ser codificado permanentemente. ( @sanssecours É o caso de YAML?)

No entanto, para TOML, ele simplesmente diz "Base64 ou outra codificação ASCII ou UTF-8 adequada", portanto, outros plug-ins binários podem ser usados. Portanto, a solução atual tem vantagens, pois os usuários podem montar outros plug-ins binários conforme desejado ou necessário.

@ bauhaus93 - infos/needs = base64 deve ser alterado para - infos/needs = binary .

Primeiro, essas chaves não-folha com valores são estranhas em quase todas as circunstâncias e devemos realmente recomendar que elas sejam evitadas.

São muito comuns em muitos formatos. E podem ser muito úteis quando você estende uma especificação (cria subchaves a partir de chaves que possuem valores).

[Chaves do diretório] Parece que @ markus2330 (um pouco) concorda comigo neste ponto.

Concordo que os plug-ins de armazenamento precisam lidar com isso (talvez com uma biblioteca, mas não com o plug-in "valor do diretório", pois o escape não funciona e o escape correto é uma das principais tarefas de um plug-in de armazenamento).

Ok, basicamente você só o usa para verificar.

Não concordo com a frase "o plug-in toml usa o plug-in type ". Na versão atual, ele recomenda apenas type .

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

Mesmo se type fosse declarado como needs , eu não o chamaria de "usando". toml realmente não tem nenhum controle direto sobre type . É por isso que eu disse que toml depende de type . Ele espera que type faça certas coisas de uma certa maneira, mas eu não posso fazer nada, se esse não for o caso.

Pode funcionar melhor se eu retrabalhar o nº 666 e emitirmos avisos durante a montagem.

Eu concordo. Talvez até em cada kdbGet também, a menos que uma chave especial "Reconheço que este ponto de montagem usa plug-ins experimentais" tenha sido definida.

base64 não é a única maneira de codificar dados binários.

Isso é na verdade um argumento para um plugin binary . Embora eu ainda deseje uma interface através da qual o plug-in funcione com uma única tecla por vez, isso poderia gerar alguma economia de memória e talvez economia de desempenho também. (Mas isso é outro problema)

São muito comuns em muitos formatos.

Você tem um exemplo?

E podem ser muito úteis quando você estende uma especificação (cria subchaves a partir de chaves que possuem valores).

É verdade, mas, nesse caso, eu recomendaria uma solução "um ou outro" (do ponto de vista do usuário final). Ou você usa a chave antiga com o valor único ou usa a nova versão com subchaves. Caso contrário, a configuração provavelmente será confusa.

Para ser claro, não acho que as chaves não-folha com valores nunca devam ser usadas, mas devem ser evitadas se possível e raramente (se nunca) são a solução preferida.

mas não com o plug-in "valor do diretório", pois o escape não funciona

Em # 3256, sugeri o uso de metadados para resolver problemas de escape. Além disso, existem minhas idéias de # 3223 que resolveriam o problema de escape (para cada caso de uso não apenas directoryvalue ), bem como algumas outras coisas. Veja também a proposta (muito formal) . Acrescentarei explicações simples em inglês hoje ou amanhã a esse documento, pois ainda sou muito a favor dessas mudanças.

@sanssecours como os plug-ins YAML lidam com a conversão de tipo?

Yan LR e YAML CPP usam o plugin type para booleanos. YAML CPP também usa o plugin base64 para dados binários.

base64 não é a única maneira de codificar dados binários. Para padrões em que base64 é necessária, pode ser codificado permanentemente. ( @sanssecours É o caso de YAML?)

Sim, pelo que eu sei, os dados binários em YAML sempre usam a codificação Base64.

[chaves não-folha com valores] Você tem um exemplo?

XML e a maioria dos dialetos INI (já que permitem key=value mesmo quando [key] existe)

É verdade, mas, nesse caso, eu recomendaria uma solução "um ou outro" (do ponto de vista do usuário final). Ou você usa a chave antiga com o valor único ou usa a nova versão com subchaves. Caso contrário, a configuração provavelmente será confusa.

Sim, isso parece razoável. Depois de saber que algo é uma seção, você geralmente move o valor para algum lugar dentro da seção.

Por exemplo, deluser.conf tem BACKUP = 0 e BACKUP_TO = "." . Com as seções, a maioria dos aplicativos usaria BACKUP_ENABLE vez de simplesmente BACKUP .

Além disso, existem minhas idéias de # 3223 que resolveriam o problema de escape (para cada caso de uso, não apenas directoryvalue ), bem como algumas outras coisas.

Já atualizei a proposta em # 3223. Espero que agora seja mais fácil de entender (ainda é muito longo).

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

A grande questão é quem vai implementar tudo isso. Está muito longe do status quo, ou seja, dá muito trabalho (só as mudanças de terminologia dão muito trabalho). Se você quiser implementar, você pode criar um PR com a proposta e eu comento. Caso contrário, devemos dar um passo para trás e pensar em soluções viáveis ​​ao nosso alcance.

Por falar nisso. a primeira parte da proposta é, na verdade, um tutorial maravilhoso sobre como funcionam os nomes-chave. Seria incrível ter isso como um tutorial. : sparkling_heart:

A grande questão é quem vai implementar tudo isso.

Essa é sempre a questão ...

Está muito longe do status quo, ou seja, dá muito trabalho (só as mudanças de terminologia dão muito trabalho).

As mudanças na terminologia são definitivamente a maior parte, especialmente alterando toda a documentação. No entanto, isso não precisa ser feito por uma pessoa. Essas mudanças são bastante simples, elas são entediantes, então qualquer pessoa pode ajudar, mesmo sem um amplo conhecimento sobre o código. Na maior parte do tempo, trata-se apenas de ler toda a documentação e substituir ocorrências de coisas como "nome base".

Se você quiser implementar, você pode criar um PR com a proposta e eu comento. Caso contrário, devemos dar um passo para trás e pensar em soluções viáveis ​​ao nosso alcance.

Vou começar um PR, mas se terei tempo de terminar (sozinho) no previsível, não sei dizer.
Já tenho uma filial local na qual todas as chamadas para keyBaseName , keySetBaseName e keyAddBaseName foram substituídas por keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart e keyAddUnescapedPart / keyAddLiteralPart . Eu criei isso usando uma substituição de expressão regular semiautomática depois de escrever a primeira proposta.

Mas nesse ramo as novas funções são apenas #define s para as antigas, então a implementação real ainda precisa ser escrita e, em seguida, os testes e provavelmente os plug-ins de armazenamento precisam ser atualizados.

O maior problema para mim seriam os plug-ins de armazenamento. Posso implementar as atualizações para o núcleo e os testes e talvez um plug-in de armazenamento. Mas eu preferiria, se não tivesse que estudar o código de todos os plug-ins de armazenamento e descobrir todas as complexidades de todos os formatos.

Por falar nisso. a primeira parte da proposta é, na verdade, um tutorial maravilhoso sobre como funcionam os nomes-chave. Seria incrível ter isso como um tutorial.

É por isso que escrevi desta forma. Meu plano era reutilizar partes desta proposta para a documentação em # 3447. Não posso usá-lo 1: 1 porque deixei de fora algumas partes muito importantes (por exemplo, canônico vs não canônico).

Preciso ser franco e não dar a você nenhuma esperança errada: como você viu no LCDproc, não acontece que outras pessoas estejam concluindo tarefas rapidamente, especialmente quando elas são tediosas. Um PR que destrói todos os plug-ins de armazenamento, exceto um, não pode ser fundido. E os plug-ins de armazenamento não se beneficiam muito desse PR; na verdade, eles ficam "piores" no sentido de que, de repente, produzem erros de sintaxe em arquivos que podem ser analisados ​​agora. Isso não significa que, em geral, seja uma má ideia. Com alguns refinamentos, pode ser melhor do que o status quo, mas simplesmente não vejo como podemos fazer uma tarefa tão grande com tantas outras tarefas urgentes em aberto que temos agora.

Portanto, vamos nos concentrar no # 3447 (docu), finalmente concluindo o # 2969, melhorando o plug-in TOML e outros tópicos importantes de que precisamos para 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 e https: // github.com/ElektraInitiative/libelektra/milestone/14). Assim que tiver uma boa aparência, podemos ver quais outras ideias podemos realizar.

Para mim, a conclusão desta discussão é que definitivamente há necessidade de bibliotecas para tornar mais fácil escrever plug-ins de armazenamento, já que a abordagem de plug-in não funcionou (exceto para binários veremos). Essa conclusão deve estar no tutorial do plug-in de armazenamento.
@ bauhaus93, você pode continuar com o tutorial do plug-in de armazenamento? Você tem muitos insights agora, que não podem ser vistos olhando para o código-fonte do plugin toml.

Um PR que destrói todos os plug-ins de armazenamento, exceto um, não pode ser fundido.

Eu não esperava que ninguém fundisse tal PR ... Eu apenas disse que seria bom se outras pessoas pudessem ajudar com atualizações para plug-ins de armazenamento. Idealmente, o autor original do plugin. Depois do # 3491, alguns dos plug-ins de armazenamento mais complexos serão removidos de qualquer maneira, de modo que toda a tarefa será mais fácil.

E os plug-ins de armazenamento não se beneficiam muito desse PR; na verdade, eles ficam "piores" no sentido de que, de repente, produzem erros de sintaxe em arquivos que podem ser analisados ​​agora.

Este não deve ser o caso. Há até uma explicação parcial no final da proposta . AFAIK não deve haver um caso, em que um plugin de armazenamento deve rejeitar um arquivo, porque ele não pode ser traduzido em um KeySet .

A única exceção seriam os formatos, que usam diretamente os nomes-chave da Elektra (com ou sem escape). Eles podem aceitar menos arquivos após esta proposta do que antes. Mas, uma vez que a sintaxe desses arquivos sempre dependeu da sintaxe dos nomes de chave, isso era totalmente de se esperar.

Com alguns refinamentos, pode ser melhor do que o status quo, mas simplesmente não vejo como podemos fazer uma tarefa tão grande com tantas outras tarefas urgentes em aberto que temos agora.

Nunca esperei que essa proposta fosse adotada imediatamente. Mas acho que devemos definitivamente considerar implementá-lo antes de 1.0. Assim que o 1.0 for lançado, a proposta seria uma grande mudança inovadora. Não acho que lançar uma versão 2.0 mesmo 1 ou 2 anos após a 1.0 (deixa pra lá antes disso) seria uma boa ideia, considerando o público-alvo da Elektra.

Portanto, vamos nos concentrar em # 3447 (docu), finalmente concluindo o # 2969, melhorando o plugin TOML e outros tópicos importantes de que precisamos para 1.0

Eu concordo totalmente. Mas, novamente, ainda devemos considerá-lo, porque após o lançamento do 1.0, adicionar mudanças significativas será muito difícil por um bom tempo.

Para mim, a conclusão desta discussão é que definitivamente há necessidade de bibliotecas para tornar mais fácil escrever plug-ins de armazenamento

👍

exceto para binário pode ser visto

IMO, o caso dos valores binários é muito diferente. É uma tradução de valor-chave 1: 1, como muitas outras ( rgbcolor , macaddr , ipaddr , etc), portanto, um plugin é realmente adequado aqui. No entanto, como eu disse, uma nova API de plug-in que lida com apenas uma chave por vez pode ser uma melhoria. Mas isso pode ser facilmente adicionado após a 1.0, uma vez que não seria uma alteração significativa se feito corretamente.

mais -> deve?

Sim, eu vejo da mesma forma: não é realista que essa mudança aconteça uma vez que 1.0 for lançado (o propósito de 1.0 é congelar tais decisões para que outros possam confiar nele) e seria bom ter essas melhorias antes . Mas, como disse: realmente precisamos nos concentrar em fazer as coisas críticas e não perder nossa energia em batalhas legais que não podemos vencer com nossa força de trabalho atual.