In questi mesi, nel pentolone del progetto API ribollono parecchie novità, come l'adozione dell'ereditarietà multipla e un nuovo modello di constructor per i servizi UNO.
Le novità comportano sempre dei cambiamenti, perciò l'eterna discussione sulla dicotomia (vera o presunta) tra evoluzione e stabilità si è riaccesa in modo vivace, alimentata anche dal contributo autorevole di sviluppatori indipendenti come Ariel Constenla-Haile.
La stabilità in questo contesto non va però intesa come l'attitudine di un programma a non andare in crash ogni qualvolta che un raggio cosmico dovesse passare nelle vicinanze.
La trave portante dell'API infatti, non è tanto l'implementazione quanto l'insieme delle specifiche che definiscono e regolano l'interazione tra un programma client e il programma host (OpenOffice.org)
Background
In termini molto generali, si può immaginare l'API come una sorta di vocabolario predefinito, con tanto di convenzioni grammaticali e lessicali, che il programma client deve utilizzare per poter controllare OpenOffice.org.
Il programma client è generalmente sviluppato da terze parti, siano esse semplici utenti che utilizzano le macro o sviluppatori professionisti che integrano OpenOffice.org nelle loro soluzioni software.
Per questo motivo è molto importante che, una volta che gli sviluppatori API abbiano stabilito il “vocabolario” e la “ grammatica” per comunicare non ci siano stravolgimenti ad ogni nuova versione di OpenOffice.org.
Pros&Cons
La politica del progetto API, fortemente difesa da Jürgen Schmidt attuale leader del progetto, è sempre stata coerente, anzi direi granitica su un punto: ciò che è pubblicato non deve essere modificato.
In altre parole, la definizione di un sevizio o di un interfaccia vengono considerati come un contratto vero e proprio tra lo sviluppatore API e i suoi utenti ovvero gli sviluppatori esterni che utilizzano i servizi e le interfacce.
Agli inizi del progetto questa fermezza di propositi venne giudicata indispensabile per creare un clima di fiducia negli sviluppatori esterni, che guardavano con interesse e valutavano se valeva la pena di investire risorse nell'adozione di questa nuova piattaforma.
Tale politica ha indubbiamente pagato. La comunità degli sviluppatori esterni in questi anni è cresciuta enormemente non solo quantitativamente ma anche qualitativamente, raggiungendo livelli di competenza molto elevati.
Per contro, ci sono stati anche dei costi in termini di difficoltà evolutive, basti pensare al difficilissimo parto del componente Base, introdotto con la versione 2.0
Bisogna ricordare che OpenOffice.org era dotato un componente database fin dalla prima versione. Tale componente non aveva una propria interfaccia grafica separata. In pratica il componente base, in background, forniva a tutti gli altri componenti la capacità di interagire con i database.
Nel passaggio alla versione 2.0 questo approccio “pervasivo” venne trasformato in quello basato su documenti che vediamo attualmente.
Questa trasformazione richiese complessi adattamenti se non addirittura veri e propri contorsionismi a livello di API proprio perché la scelta fu quella di mantenere il più possibile la compatibilità con il codice di terze parti preesistente.
Il ciclo di sviluppo API
In altri casi il “costo” per mantenere la compatibilità con il codice preesistente si manifesta in modi più subdoli.
Il ciclo di sviluppo dell'API prevede che un servizi o un interfaccia di nuova creazione siano immediatamente resi pubblici, ma etichettati inizialmente come unpublished.
Questo significa che possono essere utilizzati ma che potrebbero essere soggetti a modifiche e correzioni incompatibili con il codice preesistente.
Trascorso un certo periodo e dopo aver ottenuto qualche feedback da parte dell'utenza il servizio o l'interfaccia vengono ri-etichettati come published e da questo momento non potranno più subire modifiche.
Questo meccanismo ha fatto si che gli sviluppatori tendessero a non documentare pubblicamente i nuovi servizi e comunque, una volta documentati venivano marcati come unpublished per un tempo lunghissimo proprio per non vedersi congelare il proprio lavoro e per tenere sempre aperta la possibilità di correzioni.
Di fatto, questo atteggiamento riluttante rischiava, e rischia tuttora, di vanificare il contratto con gli utilizzatori.
(se ogni nuova interfaccia rimane unpublished a tempo indeterminato la stabilità non sarà mai garantita)
Per questo motivo i mantainer del progetto API hanno comunque obbiettato in più casi che, se un servizio o un'interfaccia sono rimasti disponibili per lungo tempo verranno comunque considerati non modificabili, indipendentemente dallo stato di pubblicazione.
Questo è in palese contraddizione con le regole di pubblicazione volute dagli stessi mantainer, ma, l'orientamento generale è chiaro, si tende a preservare (e con giustissima ragione, aggiungo io) la compatibilità e il contratto con l'utenza ad ogni costo.
