Il wrapping di uno strumento da riga di comando (wget, curl) è una pratica "buona"?

La mia opinione:

1. Reinventare la ruota è male. Non farlo Lo sappiamo tutti.
2. Il wrapping di uno strumento da riga di comando è sempre un po 'brutto. Mancanza di integrazione utile, mancanza di controllo del flusso, doversi preoccupare di tutti i tipi di citazioni infernali.

Tuttavia, in questo caso, c'è una soluzione perfetta: basta usare libcurl . È comunque ciò che costituisce il coraggio di curl e si evita tutta la cattiveria del wrapping di uno strumento da riga di comando.

Avvolgere un'app da riga di comando non è buono o cattivo, è solo una tecnica.

Il "buono" e il "cattivo" entrano in gioco quando si esaminano gli approcci alternativi. È meno probabile che sia "buono", ad esempio, se si esegue il wrapping di un eseguibile da riga di comando quando è disponibile una libreria più adatta . D'altra parte, non c'è assolutamente nulla di sbagliato nel wrapping dell'eseguibile della riga di comando quando questo è l'unico strumento disponibile per quello che stai facendo.

Nel tuo caso specifico, sarei molto sorpreso se non ci fossero molte altre opzioni a tua disposizione oltre al wrapping di cURL.

Penso che sia più una questione se si desidera che questa funzionalità sia incorporata nel software o meno. Non importa come scuote, se la funzionalità è necessaria finirai con un "ricciolo" da qualche parte. Ma ti avverto che c'è una certa complessità in entrambi i casi.

Se "curl" è all'interno del tuo software:

Quindi devi codificarlo tu stesso e sì è un problema, ma libcurl è abbastanza dannatamente solido per quanto riguarda le librerie e finchè il tuo codice si costruisce puoi stare tranquillo che l'utente è a posto.

Se "curl" è esterno al tuo software:

Allora sì è più facile per te dal punto di vista del codice ma hai trasformato il tuo lavoro di programmazione di basso livello in un lavoro di amministrazione del sistema, dal momento che ora lo farai,

• è necessario assicurarsi che il software possa trovare arricciatura sul sistema. (La distribuzione in ambienti diversi si complica)
• trattare con gli utenti su sistemi che non hanno arricciatura installata. (Quanto è grande questo affare dipende dalle piattaforme di destinazione, ma dovrai assicurarti che le persone sappiano come installarlo se non lo hanno già.)
• (probabilmente) è necessario creare un sistema di configurazione generale che permetta all'utente di aiutare il software a trovare arricciature (o qualcosa di equivalente) che consente al software di funzionare quando il ricciolo è già presente ma il metodo da te fornito non è riuscito. Qui una buona configurazione del file di configurazione può aiutarti ...

L'amministrazione del sistema e l'implementazione robusta in diversi ambienti possono diventare complesse (proprio come la codifica diretta), quindi mi sembra che ci siano vantaggi e svantaggi per entrambi.

Scegli il tuo veleno.