Newsgroup: it.comp.programmare
Titolo: Quale sistema per i plugin?

Sono alle prese con la necessità di implementare un sistema di "plugin" 
nel mio programma, cioè un sistema per cui il programma apre un file, 
legge alcuni dati di quel file e in base a questi carica la DLL 
appropriata per gestire il resto dei dati del file.
DLL che saranno scritte non da me ma da altri, interessati a estendere e 
potenziare il programma (si spera). Vabbè, una volta che il sistema sarà 
creato e funzionante magari ne approfitterò anch'io...
Comunque, nella mia testa la DLL-plugin dovrebbe esportare una funzione 
che esamina un file (o un buffer dati) e ritorna un bool per dire se può 
gestirlo oppure no, e poi dovrebbe ricevere in fase di inizializzazione 
l'handle del file per leggerselo con comodo (o è pericoloso, ed è meglio 
fargli usare una funzione interna del programma "nascondendo" il file??) 
e poi aprirsi una finestra per visualizzare quello che deve 
visualizzare. In più dovrebbe avere una funzione da chiamare per 
ricevere ordini e dati accessori (preferenze ed opzioni settate per 
es.). Un problema aperto è il modo di far comunicare i plugin fra loro 
(potrebbe far comodo, ma poichè non so cosa a priori faranno i plugin 
non riesco a pensare a un sistema abbastanza generale).
Questo mio schema logico vi convince o ci sono punti deboli a cui non ho 
pensato? Esiste uno standard per creare meccanismi di questo tipo, e se 
sì qual'è? E soprattutto dove trovo le specifiche??

 sì qual'è? E soprattutto dove trovo le specifiche??
Bisognerebbe sapere che linguaggio vorresti utilizzare per implementare 
la cosa.
Se parli di VB6 bisogna usare COM, se parli del .NET si usano le 
interfacce e se parli di altro ancora... non so.
S.

 interfacce e se parli di altro ancora... non so.
C++ Builder 6

 C++ Builder 6
Bassissimo livello: sotto un sistema POSIX-ish, useresti dlopen() e
dlsym() per caricare la DLL e ottenere un puntatore alla funzione con un
dato nome (C, però, non C++ -- attento al mangling, usa extern "C"). So
praticamente per certo che Windows ha equivalenti a queste due chiamate
ma ora non mi ricordo quali siano (mi pare che LoadLibrary() sia
l'equivalente di dlopen()).
Livello più alto: puoi usare COM per esporre classi che implementino una
data interfaccia, ma di nuovo non so dirti esattamente come.
 - ∞

 data interfaccia, ma di nuovo non so dirti esattamente come.
So in teoria cos'è un oggetto COM ma non li ho mai usati, nè tantomeno 
programmati. Vista la pessima fama che li circonda preferirei evitare... 
a meno che non ci sia un motivo davvero buono per usarli (e impararseli).

 a meno che non ci sia un motivo davvero buono per usarli (e impararseli).
La butto lì: hai valutato, come alternativa ai plugin, di dare la 
possibilità agli utenti di scrivere estensioni della tua applicazione 
tramite qualche linguaggio di scripting?
S.

 tramite qualche linguaggio di scripting?
No, veramente no... la mia applicazione deve visualizzare una mole 
notevole di dati in modo assai strutturato, i plugin servirebbero a dare 
a chiunque la possibilità di scriversi il proprio "analizzatore/viewer 
di dati" senza doversi scrivere anche tutto il resto del programma.
Farlo con un linguaggio di scripting invece che con dei plugin... no, 
non ci avevo pensato. Così a naso non mi pare granché utile, ma vale la 
pena ragionarci sopra. Magari per una delle prossime versioni, se ce ne 
saranno...
grazie comunque a tutti

sì qual'è? E soprattutto dove trovo le specifiche??
Non conosco standard per queste operazioni, ma potrebbe darsi...

comunicare coi sockets.
In questo caso, i socket c'entrano come i cavoli a merenda :-)

 host.
Questo mi spiazza un pò, l'idea era di permettere appunto ai plugin di 
aprire una finestra e gestirsela loro per visualizzare i dati nel modo 
che preferivano (testo o grafici, o 3D o quello che gli pare) lasciando 
che l'applicazione principale fornisse le "viste di base" e gli 
strumenti standard.
Perchè è male lasciare che un plugin si occupi della visualizzazione? 
Solo per questioni di omogeneità di look&feel e interfaccia o per 
problemi più seri?
Si potrebbe pensare a un meccanismo per cui il programma crea la 
finestra e (se richiesti) i menu e le icone di interfaccia e poi lascia 
libero il plugin di lavorare nel DC della finestra stessa. Così andrebbe 
meglio?

 saranno...
Potrebbe invece essere la mossa vincente. 
Tipicamente è più facile estenderla (per i tuoi utenti) e le loro
estensioni è meno probabile che rendano instabile il tutto. 
Oltretutto poi verrà anche a voi la tentazione di estenderla con
suddetto sistema. :P
-- 
-riko


Senza contare che poi anche visualizzare i dati rimane semplice... una 
paginetta html, del codice javascript et voilà.
S.

 paginetta html, del codice javascript et voilà.
No... la visualizzazione è interattiva. Si agisce sui dati visualizzati, 
li si modifica e la visualizzazione cambia.

 li si modifica e la visualizzazione cambia.
Certi linguaggi di scripting come Lua sono progettati per l'integrazione
in applicazioni C/C++, ma richiedono comunque un forte lavoro di
scrittura del "ponte".
 - ∞

meglio?
Mi piace di più.

 li si modifica e la visualizzazione cambia.
Che GUI toolkit usate?
Nella felice ipotesi che sia Qt, c'č il suo linguaggetto bello e pronto.
-- 
-riko

 Nella felice ipotesi che sia Qt, c'è il suo linguaggetto bello e pronto.
No, non è Qt... ci avevamo fatto 1 pensierino, ma non abbiamo esigenze 
di portabilità o di interfaccia figa&sofisticata, per cui nix