Di solito non accendo <em>flame</em>: ci partecipo solo (grazie ai poteri della <em>I-can-t-believe-it-s-not-Asbestos</em> tuta che mi è servita per anni su Usenet) perché mi diverte vedere le buffe reazioni degli esseri umani (misantropo umanista? <em>You bet!</em>).
Stavolta, però, me la stanno tirando fuori dalle carni.
Chiunque segua <em>desktop-devel-list</em> sarà al corrente che non nutro grande simpatia per Tracker, il calderone di indexer/database/interfaccia grafica/<em>kitchen sink</em>/quello che sarà questa settimana che <a href="http://pollycoke.wordpress.com">alcuni</a> vorrebbero avere una maggiore integrazione con GNOME.
Premetto subito che io <strong>non odio</strong> Tracker: mi stanno cordialmente sulle balle le modalità con cui viene evangelizzato e, soprattutto, sviluppato. Dopo un anno e rotti in cui è stato riscritto almeno tre volte, cambiato il database, cambiato l’indexer, aggiunte feature e realizzato poco testing, ancora manca una cazzo di API decente per permettere a me, sviluppatore, di poterlo utilizzare. Si, perché il fine ultimo di Tracker è, evidentemente, immagazzinare il maggior numero di informazioni sui vostri file e poi <strong>non utilizzarle</strong>, dato che esiste solo una serie di <em>remote procedure calls</em> per D-Bus e nient’altro. Ma certo, se ho bisogno di estrarre dati mi basta usare Python. Solo che non io posso riscrivere GNOME in Python (o C++, o C#, o D, o COBOL o <code>${WHATEVER_LANGUAGE_ZEALOTS_WILL_PROPOSE_NEXT}</code> – in fondo, abbiamo milioni di linee di codice da riscrivere da capo, che sarà mai), e gli utenti non hanno un cazzo di Cray su cui far girare uno GNOME scritto in Python (i requisiti di memoria dopo otto ore di utilizzo sono quelli). <em>By the way</em>: menarmi il torrone su quanto Tracker sia buono con la mia CPU e la mia RAM e poi dirmi che se voglio usarlo devo ridurmi a scrivere un’applicazione in Python è prendermi per culo – puro e semplice; e io non sopporto quando mi prendono per il culo.
Prendiamo HAL, l’<em>Hardware Abstraction layer</em> scritto per evitare di dover pasticciare con device, permessi e stronzate varie; è composto da <acronym title="Remote procedure call">RPC</acronym> ma ha anche ben <strong>due</strong> librerie che mi permettono di non dover usare D-Bus direttamente. Perché? Perché HAL è scritto da qualcuno sano di mente, probabilmente, che pensa che l’utente non se ne fa una sega di HAL in quanto tale – l’utente è esposto ad applicazioni che usano HAL a loro volta; gli utenti di HAL sono <strong>gli sviluppatori</strong>, e se non do agli sviluppatori un’API sensata come diavolo faranno a scrivere applicazioni? Tracker occupa una nicchia analoga: gli utenti non sanno cosa sia Tracker, a cosa serva o come lo faccia; sanno solo che possono aggiungere una tag a un file e cercare file usando lo stesso tag. Se un utente si eccita con il fatto che esista Tracker è un cazzo di geek, e <strong>non è per loro che io contribuisco a GNOME</strong>.
Quindi, prego qualcuno di mettersi a scrivere un’API coi contro cazzi per permettermi di scrivere applicazioni con Tracker; non <em>widget</em>: voglio scrivermi i <strong>miei</strong> widget senza aspettare sei mesi che qualcuno ne aggiunga uno che mi serve. Perché sono io che scrivo applicazioni per GNOME, non "gli utenti"; e se io non sono in grado di scrivere applicazioni per GNOME usando Tracker vorrà dire che sarò costretto a reinventarlo tra sei mesi.
Giuro, mi basta qualcosa che mi dia un <code>GObject</code> a cui far eseguire un match, e abbia segnali che mi dicono cosa la mia richiesta ha trovato. Perché non c’è ancora? Perché gli sviluppatori e chi contribuisce a Tracker ha deciso di perdere il suo tempo per scrivere front-end per la Deskbar applet, mantenere branch parallele di Nautilus e violentare il Search Tool invece di permettere ai maintainer di questi progetti di fare il loro lavoro?
</rant>