Executando um programa externo vs confiando na biblioteca subjacente

5

Contexto: Eu queria mudar uma configuração dentro do Xfce e descobri que a maneira de fazer isso é através do xfconf. Meu primeiro pensamento foi instalar os arquivos de desenvolvimento do libxfconf ( libxfconf-0-dev ) e examinar a API. Eu procurei para ver se há um exemplo em algum projeto de código aberto e encontrei uma biblioteca que, em vez de usar a biblioteca libxfconf diretamente, apenas executa a CLI da biblioteca, xfconf-query e verifica se o comando foi um sucesso para alcançar o mesmo resultado.

Originalmente pensei que essa solução era grosseira, mas depois de pensar ainda mais, vi algumas vantagens:

  • Economiza tempo, especialmente quando a API é complicada ou mal documentada.
  • Pode ser feito facilmente em qualquer linguagem de programação.
  • Reduz a complexidade do seu próprio binário (tanto no código quanto na compilação).

Por outro lado:

  • É muito mais lento.
  • Pode ser propenso a erros (por exemplo, os parâmetros são corretamente encapsulados e passados?).
  • O usuário pode ter uma versão diferente da CLI instalada (ou, pior ainda, pode ter um binário diferente com o mesmo nome).

Tendo isso em mente, supondo que uma biblioteca também ofereça uma CLI, quando, se alguma vez, é bom apenas chamar o binário da CLI diretamente, ao invés de confiar nas chamadas da biblioteca?

    
por fstanis 28.08.2017 / 01:18
fonte

1 resposta

7

Como sempre, depende . Eu tive que tomar esse tipo de decisão várias vezes no passado, então tentarei dar algumas orientações gerais a partir dessa experiência.

Primeiro, isso só faz sentido onde um programa oferece uma CLI, bem como uma interface de biblioteca. Se a única interface "oficial" para um programa é a CLI, então é melhor você usá-la. No entanto, para casos em que ambos os tipos de interfaces estão disponíveis, isso depende de várias coisas. Alguns exemplos populares, fora da minha cabeça:

Você já mencionou alguns prós e contras, eis alguns aspectos adicionais a serem considerados:

  1. A qualidade das APIs (API CLI vs. lib)

  2. Execução "em processo" (lib) vs. execução "fora do processo" (CLI)

  3. O tipo de comunicação necessária entre o aplicativo em uso e o programa / biblioteca chamado.

  4. problemas de licenciamento (por exemplo, se a biblioteca / programa que você deseja usar está sob GPL)

  5. testabilidade

  6. Outros fatores, como código já existente, o ambiente de destino, problemas relacionados à segurança, problemas de know-how e assim por diante.

Para alguns desses programas / libs, a API da biblioteca e a CLI não oferecem exatamente o mesmo conjunto de características, então é provavelmente a primeira coisa a procurar.

IMHO as principais diferenças entre um programa CLI versus um lib são resultantes da comunicação fora do processo / em processo. Isso força uma abordagem de comunicação muito diferente entre seu programa e o lib / program, e também diferentes manipulações de erros. "fora de processo" tem a vantagem de fazer com que o programa chamado seja executado em um isolamento melhor e oferece a possibilidade de lidar com falhas de programa de uma maneira mais elegante. No caso do software GPL, também tem a vantagem de evitar os aspectos virais da GPL.

Como você já mencionou, executar um processo separado normalmente será mais lento do que chamar uma biblioteca diretamente. No entanto, se isso for realmente significativo para um caso de uso específico, depende muito do caso de uso específico. Para alguns casos, usar a execução fora do processo pode tornar o runner mais rápido , por causa da execução paralela implícita.

As opções de comunicação com um programa CLI são normalmente muito mais restritas, especialmente quando os parâmetros de linha de comando (e talvez alguns arquivos) são a única maneira de alimentar entrada no programa, e um código de retorno e arquivos de saída são a única maneira de obter saída. Isso torna a utilização de uma biblioteca muitas vezes obrigatória quando se precisa de um protocolo de comunicação mais complexo. Se o caso de uso exigir que ele trabalhe com estruturas de dados retornadas de chamadas de lib e as repassa para outras funções da biblioteca, ou se o caso de uso precisar de retornos de chamada, uma CLI não fará muito sentido. Por exemplo, libxslt / libsml lhe dá a possibilidade de acessar o DOM inteiro de um arquivo XML e trabalhar com ele em seu próprio programa. Não faço ideia de como isso deve ser feito de maneira comparável usando apenas o cliente de linha de comando xsltproc. No entanto, se você precisar apenas de um script xslt para ser executado em algum arquivo xml de entrada e obter o arquivo resultante para processamento adicional, o uso de xsltproc pode ser suficiente ou mesmo preferível.

Sobre a testabilidade: com o ImageMagick, tornei a experiência mais fácil de testar comandos CLI singulares isoladamente e, em seguida, deixei que um programa chamasse a CLI, com exatamente os mesmos parâmetros. Por outro lado, usar um cliente de banco de dados CLI para testar alguns SQLs e depois usar esses SQLs diretamente em conjunto com uma API do banco de dados em forma de lib também me serviu muito bem também.

Sobre o seu "usuário pode ter uma versão diferente da CLI instalada" argumento: bem, isso também pode ser o caso quando se usa uma lib, eu acho? Para libs, o ambiente pode fornecer a verificação automática da versão pronta para uso, no entanto, muitos programas CLI permitem que você peça um número de versão, portanto, dá ao menos uma oportunidade de fazer algumas verificações de integridade. de antemão.

Portanto, em resumo, não há uma solução "certa" ou "errada" ou "melhor" aqui, você precisa analisar o caso individual e tomar uma decisão para o seu caso específico.

    
por 28.08.2017 / 11:17
fonte

Tags