Kibana: Usando ids exclusivos para plugins na nova plataforma

Criado em 7 jul. 2017  ·  3Comentários  ·  Fonte: elastic/kibana

Na versão atual da nova plataforma, os plugins são identificados por uma string (por exemplo, para definir dependências).

Eu gostaria de discutir como tornar esses ids de alguma forma mais exclusivos, por exemplo, usando um nome java como org.elastic.timelion ou de.timroes.demo-plugin . Dessa forma não poderia acontecer mais colisões de nomes, porque as pessoas usam nomes muito simples e você tem vários plugins chamados, por exemplo 3dcharts .

Outro esquema de nomenclatura poderia estar usando escopo do tipo npm, por exemplo, @elastic/timelion ou @timroes/demo-plugin . Acho que ambas as sugestões têm seus prós e contras.

Usar o escopo é mais parecido com JavaScript e pode ser uma vantagem se o npm for usado para gerenciamento de plug-ins. Eu vejo a vantagem em nomes Java-ish, que eu suponho que muitas pessoas não têm um usuário npm e realmente usariam um @scope que não pertence a eles, enquanto eu raramente conheci alguém, que não seria capaz de construir um nome de domínio reverenciado para um domínio privado ou empresarial.

Qualquer que seja o formato desse id exclusivo, pode fazer sentido impor esse formato na nova plataforma diretamente e proibir quaisquer novos plug-ins que não estejam em conformidade com esse esquema de nomenclatura.

<discuss>

New Platform Core discuss

Comentários muito úteis

Posso ver o benefício disso, mas também é um problema que podemos resolver a qualquer momento no futuro. Não temos uma epidemia de IDs de plugins duplicados e, quando há IDs de plugins duplicados, é excepcionalmente raro que você queira instalar esses dois plugins ao mesmo tempo. Eu gosto desse tipo de pensamento avançado sobre o potencial de desenvolvimento generalizado de plugins que a nova plataforma incentiva, mas vamos lidar com isso mais tarde, quando isso realmente se tornar um problema.

@elastic/kibana-platform o que você acha?

Todos 3 comentários

Talvez uma exceção para plugins de núcleo embutidos possa fazer sentido, pois eles não precisarão de um prefixo, mas também vejo várias desvantagens de introduzir exceções desde o início novamente.

Posso ver o benefício disso, mas também é um problema que podemos resolver a qualquer momento no futuro. Não temos uma epidemia de IDs de plugins duplicados e, quando há IDs de plugins duplicados, é excepcionalmente raro que você queira instalar esses dois plugins ao mesmo tempo. Eu gosto desse tipo de pensamento avançado sobre o potencial de desenvolvimento generalizado de plugins que a nova plataforma incentiva, mas vamos lidar com isso mais tarde, quando isso realmente se tornar um problema.

@elastic/kibana-platform o que você acha?

Vou fechar isso como uma solução não usual por enquanto. Como mencionei no meu comentário anterior, acho que as idéias aqui são sólidas, mas ainda não estamos atingindo esse problema. Podemos ressuscitar este tópico ou abrir um novo se/quando se tornar um problema comum na prática.

Esta página foi útil?
0 / 5 - 0 avaliações