[bglug] [Qt4][python] QIcon e icona presa dal web

[Dario Bertini]

grazie delle risposte...

tutte cose che comunque non mi fanno avere pace :P

vi faccio un esempio pratico per rendervi partecipi :)

Virtualbox, oltre alla normale gui che conoscono tutti, ha altri 2
modi per avere accesso alle sue funzionalità:

un tool da linea di comando ( VBoxManage ) ed un'api basata su XPCOM
(XPCOM pare faccia anche altro, tipo fornire astrazioni per i file...
ma per i nostri scopi ci basta sapere che è l'ennesimo sistema per
trasmettere messaggi fra processi diversi)

la stessa gui si appoggia sull'api xpcom per gestire le varie macchine virtuali

ebbene, l'api xpcom ovviamente ha dalla sua lo svantaggio tipico di
altri IPC: le api sono definite in un modo familiare al linguaggio col
quale il sistema IPC stesso è implementato (in questo caso, direi
C++)... prendo una pagina a caso per farvi capire:
http://www.virtualbox.org/sdkref/interface_i_bandwidth_group.html

quindi, ammettendo che il nostro software sia scritto in python, come
in oggetto, ci troveremmo la complicazione aggiuntiva di dover sapere
come gli oggetti e le interfacce xpcom si traducono nel linguaggio che
noi vogliamo usare

ora, io non ho mai provato ad interfacciarmi con queste api (non
avendo vera ragione di farlo), e non so nemmeno quanti altri software
(gui e VBoxManage a parte) la utilizzino

però sono a conoscenza di almeno un software (testdrive) che chiama
VBoxManage invece di fare accesso direttamente all'API

e la cosa mi turba abbastanza :)

insomma: per una persona che non ha mai usato prima xpcom, usare l'api
vera e propria è veramente la soluzione "più onerosa da implementare"
come dice enzo?

ed ancora: ammettendo che invece mi trovi io dall'altra parte della
barricata... mettere a disposizione una cli è forse garanzia che poi
questa verrà "abusata" da altri software, anche quando c'è un'api a
disposizione?

certo, realizzare un'api pubblica stabile ed usarla anche internamente
(come nel caso della gui di virtualbox) è una buona pratica... ma se
nessuno poi finirà per usarla sarebbe alquanto sconfortante :/


insomma: a meno di problemi di shell injection, quello di cui mi
preoccupo sono casi come questo (ne ho 3 in mente, ma forse ne ho
visti anche altri)... in cui cioè non abbiamo problemi di deploy
(perchè comunque, anche per usare un sistema IPC dovremmo avere la
garanzia che l'eseguibile dall'altra parte ci sia e funzioni
correttamente) e di performance...

ma abbiamo la necessità di chiamare codice fra diversi processi, e le
2 alternative principali sono abusare di una cli e sfruttare un'api
basata su un sistema ipc (o magari usare un qualche altro meccanismo
di "traduzione", nel caso che uno dei 2 linguaggi sia hostato da una
virtualmachine)


ovviamente c'è anche l'altro lato della medaglia: queste soluzioni non
sono pulite, ma c'è software analogo che usa queste (apparentemente?)
api più complicate

visto che alla fine, il software che usa l'approccio sporco funziona
comunque... e viene spesso usato da tantissimi utenti, qual'è stato il
vero vantaggio nell'imbarcarsi in un'implementazione pulita?

(certo, se il programmatore già sapeva a menadito come interfacciarsi,
questa domanda ha meno senso)


che ne dite?

(a parte che devo farmi meno seghe mentali :P )