Piatto ricco mi ci ficco

C'è un'aspetto che forse nessuno ha considerato nella "guerra dei desktop search engine": il fatto che, per come sta andando avanti ora, ne sopravviverà soltanto uno.

Sì perché al momento, in base a quanto so o ho letto in giro per la rete, l'unico punto su cui i vari desktop search engine stanno lavorando di comune accordo (o per lo meno l'unico punto comune a cui si possono riferire) è l'interfaccia per la definizione delle interrogazioni, cioè il progetto fd.o Xesam.

La possibilità di avere una comune "interfaccia" per effettuare una interrogazione è ovviamente cosa buonissima e giustissima, tanto per l'utente finale che cerca nei propri oggetti[1], quanto per gli sviluppatori che volessero rendere la propria applicazione "cercabile"[2]. Se poi tale interfaccia mi permettesse di scrivere interrogazioni complesse e flessibili come queste, allora tanto meglio[3].

Il punto è che ogni altro componente del search engine non è condiviso: non è condiviso il database in cui andare a cercare ciò che è indicizzato (e quindi debbo mantenere aggiornato un database per ogni search engine) e non sono condivisi gli estrattori che permettono di estrarre dati e metadati dagli oggetti (e quindi posso avere oggetti non supportati o supportati in modo diverso a seconda del search engine).

Tali mancanze precludono la modularità che da sempre contraddistingue i sistemi liberi come GNU/Linux, i vari *BSD, i vari *Solaris, modularità per la quale se un "pezzo" del sistema non mi piace, fosse esso il kernel, l'ambiente grafico, la shell, il browser, posso cambiarlo a costo tendente a zero.

Se io passo da una distribuzione di GNU/Linux a OpenSolaris, in gran parte non mi accorgo della differenza, ancor di meno me ne accorgo se entrambi usano per esempio GNOME come UI. Se io passo da Beagle a Tracker, o da un futuro GNOME con Tracker a un futuro KDE con Strigi, come prima cosa debbo reindicizzare tutti i miei oggetti - e non è detto che la cosa richieda poco tempo, anzi.

Analogo discorso per gli estrattori: guardando la questione con occhio lungimirante, non è possibile che il search engine fornisca estrattori per ogni tipo di file. Il search engine dovrebbe fornire una API o dello specifiche per far sì che sia l'applicazione stessa a fornire l'estrattore. La API, le specifiche e la disponibilità degli estrattori dovrebbe essere comune a tutti i search engine. Punto.

Se non è chiaro dove l'ultimo paragrafo volesse andare a parare, nell'attuale situazione, anche ammettendo che il search engine fornisca un modo per installare nuovi estrattori, cosa utilissima, ci troviamo nella condizione in cui ogni search engine dovrebbe/potrebbe avere, per esempio, un suo estrattore per i file JPEG fornito "out of the box" (il formato JPEG è un formato comune, non è proprio di una certa applicazione, quindi è pacifico che sia il search engine a installarlo) e dovrebbe/potrebbe avere anche un estattore per i file XCF fornito da GIMP. Non solo quindi mi troverei con N implementazioni diverse, con N numero di search engine disponibili, dell'estrattore per i file JPEG, ma gli sviluppatori di GIMP dovrebbero sviluppare N diversi estrattori.

Se dipendesse da me, accanto a Xesam cercherei di portare avanti anche una definizione e implementazione comune degli estrattori, qualcosa con una struttura simile ai plugin di GStreamer: un pacchetto extractors-base con gli estrattori di formati comuni/liberi come potrebbero essere i formati di immagini PNG, JPEG, TIFF, SVG, i formati di OpenDocument, i file di testo semplice, i file HTML, i file PDF e cose simili, e un pacchetto extractors-extra con altri estrattori per formati meno comuni e/o meno liberi come i documenti di MS Office o comunque che richiedano librerie o programmi di supporto esoterici. Il fatto che la definizione degli estrattori è comune permetterebbe poi agli sviluppatori di fornire estrattori per il formato proprietario usato dalla loro applicazione (cosa apprezzabile di certo da chi scrive software non libero, come potrebbe essere MathLab; ma ci pensate a cercare con Nautius una definizione di matrice MathLab?!?!?).

Sforando poi nel fanta-development, con estrattori comuni e interrogazioni comuni, non sarebbe possibile per un search engine interrogare direttamente il database di un altro search engine per costruire il suo, invece di scansionare tutti i file??? OK, questa forse è troppo azzardata...

Conclusioni, ammesso che se ne senta la necessità

Prima una premessa: quanti di voi seguivano lo sviluppo di GNOME nel 2002? Quanti di voi hanno mai senti parlare di Bowie J. Poag? Nel dicembre di quell'anno codesto Bowie postò sulla devel list di GNOME la proposta di un "desktop riavvolgibile". Ovviamente Mr. Poag altro non era che un troll. Però Apple promette per la prossima versione di OSX una applicazioncina dal nome Time Machine, che... beh, installatevi tutti i vari plugin di GStreamer e guardatevi il video nella pagina, è molto più chiaro di molte parole.
Seth Nickell provò tempo fa a implementarlo in GNOME, come parte di un ambizioso progetto dal nome Storage, ma questo era talmente carico di funzionalità che cadde nel dimenticatoio prima ancora di diventare un minimo usabile. BTW ma che fine ha fatto Seth?!?!?

Con la prossima versione di MacOS Apple darà quindi ai suoi utenti qualcosa di molto simile a quello Storage sognato da molti pochi anni fa. Apple può farlo, non perché sia più brava, ma perché deve vedersela solo con se stessa: è lei che decide quale search engine fornire, quale file sytem, quale interfaccia per gli sviluppatori, non ha "competizione" tra diverse istanze. Ho deciso di inserire questa funzione e lo faccio in questo modo.

Per il software libero è diverso. Non che sia peggio, a me piace pensare e avere la possibilità di scegliere tra diversi progetti con stesse finalità, anche perché le migliorie di uno si riflettono nell'altro, ma, come il progetto freedestkop ci ha insegnato, è necessario permettere l'interoperabilità affinché tutti possano trarre vantaggio da questa varietà di contributi.

-------------------
[1] nel senso di non solo documento o immagine, ma anche conversazioni IM, contatti, calendari...
[2] e badate bene che per applicazioni "cercabili" intendo cose come F-Spot o Rhythmbox: se ho già un motore per definire delle query con cui limitare gli oggetti mostrati, perché mai dovrei scrivere nuovo codice?
[3] ovviamente per permettere agli sviluppatori di costruire applicazioni cercabili, il search engine deve permettere interrogazioni siffatte.