HomeStrigi diventa un servizio di KDE: polemica, vantaggi
In News il 28/07/08 @ 18:19 trackback
Mentre nel mondo GNOME ci si solletica l’ego sprecando risorse per scrivere, mantenere e finanziare due progetti paralleli e antagonisti come Tracker e Beagle1, in casa KDE ci si solletica l’ego per due progetti paralleli e antagonisti come Strigi e… Strigi2. Una differenza sostanziale però c’è: uno dei due Strigi è appena diventato parte integrante di KDE 4!
Sebastian “Nepomuksmeister” Trueg ha da poco annunciato di aver preso una decisione che, al modico prezzo di una piccola polemica interna, promette immediati vantaggi per tutta l’infrastruttura di indicizzazione automatizzata e di ricerca rapida per metadati all’interno di KDE 4. Dopo un controverso annuncio di qualche giorno fa, i frutti del suo lavoro sono già disponibili - a velocità da record! - nel trunk dell’svn di KDE. Per me che seguo con passione Strigi dal giorno #1 questa è una notizia golosa :)
Strigi & Nepomuk - la definizione
Sono ormai molti mesi che non riporto notizie interessanti sul versante di Strigi, quindi rinfresco un po’ la memoria per chi non sapesse di cosa si tratta.
Strigi fa parte dell’infrastruttura di Nepomuk per KDE 4, ossia le specifiche per avere un desktop semantico in grado di fornire gli strumenti per contestualizzare le operazioni svolte al computer, quali - per adesso - essenzialmente indicizzazione e ricerca dei documenti. In particolare Strigi si occupa di immagazzinare automaticamente quante più informazioni possibile sui nostri dati, a partire dai semplici normi dei file fino ad arrivare all’estrapolazione dei metadati. A banale esempio: artista, album e titolo di un brano musicale.
Non è competenza di Strigi invece, ed è già possibile farlo adesso, fornire manualmente indicazioni contestuali a tali documenti usando ad esempio la possibiltà di aggiungere etichette, commenti e giudizi tramite il file manager Dolphin, e in futuro tramite il visore di immagini Gwenview, il lettore Amarok e quante più applicazioni possibile.
Strigi & Strigi - la polemica
L’oggetto del contendere è in realtà una piccola ma significativa parte di ciò che è Strigi: il servizio vero e proprio. Se si guarda bene, entrambe le realizzazioni del servizio sfruttano le stesse librerie e in particolare il cuore decisivo: libstreamanalyser, scritto da Jos, l’originale autore di Strigi.
È dunque successo che Herr Trueg pochi giorni fa ha annunciato appunto3 di aver riscritto il cuore di Strigi, rendendolo un servizio di KDE e annunciandone l’immediata disponibilità anche se a discapito di un possibile attrito… Immediata infatti è stata anche la risposta piccata di Jos4, che ha ovviamente difeso la sensatezza del suo operato, volto a mantenere Strigi un servizio indipendente da KDE o qualsiasi altro ambiente, per promuoverlo come desktop-agnostico.
Strigi & KDE 4 - la notizia
In realtà non c’è stata poi tutta questa polemica, o almeno non c’è stata su Planet KDE, solo un botta e risposta appena un po’ irritato. Il risultato finale5 ad ogni modo è che adesso il servizio di indicizzazione Strigi è incluso in KDE Base e soprattutto è abilitato nella configurazione predefinita!
La nuova applet di Strigi, caricata automaticamente all’avvio
I vantaggi della implementazione di Strigi come servizio KDE sono dipendenti dal controllo e monitoraggio facilmente integrabile nel desktop, che così è possibile ottenere. Al momento si è aggiunta alla system-tray una nuova icona con il logo di Nepomuk, contenente appunto un’applet utile a tenere sotto controllo e configurare Strigi. Potrebbe venire eliminata in favore di qualche altra soluzione, attualmente in fase di studio.
La finestra di configurazione di Strigi
Io sono contento che Strigi abbia ripreso ad essere fonte di interesse, ma mi piacerebbe tanto sentire a proposito l’opinione di Flavio Castelli, se è “in ascolto”, dal momento che lui è probabilmente lo sviluppatore italiano più addentro a Strigi e più indicato per avere opinioni tecniche su eventuali vantaggi e svantaggi di questa soluzione.
Dimenticavo: chi compila KDE da svn, seguendo magari la mia guida “KDE 4.1 per Ubuntu Hardy, in un paio di ore ;)“, può godere già adesso di queste novità, ma si tratta comunque di materiale per KDE 4.2!
— Note all'articolo:
- cfr “Dannati ignavi“ [↩]
- Ma quanto sono acuto, ma quante ne invento! -.- [↩]
- cfr “Sebastian Trueg: Strigi Reloaded - The Answer to all our Problems? Hopefully to a few of them.“ [↩]
- cfr “Jos van den Oever (vandenoever): Re: Strigi Loaded“ [↩]
- cfr “Sebastian Trueg: Strigi, Nepomuk and KDE 4.2 - hopefully a good team“ [↩]
— Pagine forse correlate:
Commenti »
Una volta completata l’indicizzazione, come si fa ad usare il database creato nelle applicazioni come dolphin?
Bell’articolo Lipinho, sufficientemente completo e semplice per farmi capire di cosa si tratta e del perché dei botta risposta dei due su PlanetKde.
23 mega per 588 file ? dio mio
Fin dai primi giorni di sviluppo di Strigi ho proposto a Jos l’uso delle librerie Qt in quanto ritenevo che avrebbero portato notevoli vantaggi. La mia proposta è sempre stata bocciata dato che la sua idea era (ed è) quella di avere un programma “desktop e platform independent”. All’inizio quest’ambizione poteva avere un senso, ma IMHO ultimamente non è ha più…
Ormai è chiaro che Gnome _non_ vuole Strigi, ma preferisce qualcosa di meglio integrato come Tracker o Beagle. D’altro canto Strigi è atualmente utilizzato solamente da KDE (parlando del grande pubblico). A mio avviso è inutile cercare di mantenerlo “desktop independent”, conviene invece focalizzarsi su KDE e fornire ai sui utenti la migliore esperienza possibile.
Partendo da questo presupposto è quindi ridicolo pensare che il programma di desktop search di KDE _non_ usi ne le Qt ne le librerie di KDE. Ciò a mio avviso comporta una serie di svantaggi notevoli:
- scarso riuso del codice: non si possono usare tutte le features già presenti nelle Qt, nelle librerie di KDE e nei “nuovi pilastri” di KDE. Chiunque con delle minime nozioni di ingegneria del software può rendersi conto di quanto questo sia dannoso
- difficoltà nell’attrarre nuovi sviluppatori: è innegabile, Strigi richiede un buon quantitativo di tempo per capire come funziona internamente. Quanti sono gli sviluppatori attivi su Strigi? preferisco non rispondere….
- difficoltà nel bug-fixing: come detto prima è necessario un po’ di tempo per capire il funzionamento di Strigi e sapere “dove e come mettere le mani”. Sarebbe bello avere dei bug-day come successo con altri progetti di KDE, ma attualmente è impensabile
Passando all’accoppiata Qt/KDE libraries invece si può facilitare lo sviluppo ed il bug-fixing, attrarre nuovi sviluppatori (occasionali e non) e fornire quindi agli utenti KDE un’esperienza migliore.
Di questo e di molto altro ancora si è parlato durante l’ultima riunione di Strigi (che tra l’altro ho richiesto io a gran voce), Al meeting erano presenti anche Aseigo e Sebastian, loro come molti altri hanno condiviso le mie preoccupazioni, ma purtroppo non c’è stato niente da fare e nulla è cambiato nella mente di Jos.
Ora si è quindi verificata quella situazione che prospettavo da tempo. Come avrai capito il mio parere è estremamente positivo. A dire il vero Sebastian mi ha anticipato, era da molto tempo che pensavo a una soluzione similare, ma per motivi lavorativi/altri progetti in corso non avevo iniziato i lavori.
Ben venga quindi il lavoro fatto da Sebastian, penso che non appena avrò un po’ di tempo libero ci darò un’occhiata e molto probabilmente inizierò a dare una mano. Se devo essere proprio sincero, ci sono alcune scelte alla base della libreria libstreamanalyser che non condivido (di cui ho sempre parlato durante l’ultima riunione di Strigi), non escludo di lavorarci in futuro.
@ Flavio Castelli
> scarso riuso del codice: non si possono usare tutte le features
> già presenti nelle Qt, nelle librerie di KDE e nei “nuovi pilastri”
> di KDE. Chiunque con delle minime nozioni di ingegneria del
> software può rendersi conto di quanto questo sia dannoso
Potresti fare un paio di esempi concreti?
Come ha spiegato dettagliatamente Flavio, anche io (da utente kde però), sono sempre stato perplesso sullo stato di strigi. Lo “seguo” dall’inizio, ma ho trovato molto più comode e performanti soluzioni integrate come Tracker e Beagle in gnome. L’idea di rendere strigi indipendente non è totalmente sbagliata, ma come dice stesso Flavio, rischia di portare una cattiva integrazione con kde, che è poi l’unico che ne fa uso.
Quindi, ben venga una notizia simile :D Diventa già qualcosa di più allettante (e magari più facile da gestire da parte dei programmatori…).
Personalmente, da utente finale, quello che mi lascia perplesso e` la precisione di Strigi rispetto agli altri sistemi di indicizzazione. Per fare un esempio, Trarcker era molto piu` preciso rispetto a Strigi nell’indicizzare il contenuto del mio hard disk
Enrico
Ma perchè l’applet aperta ha l’icona di Xming? 0_o
@5:
Solid per fermare la ricerca quando si toglie la corrente al portatile, per esempio. Sul post di Sebastian Trueg ci sono diversi altri esempi.
@9
Questo è un bell’esempio, grazie :)
@Lex:
Per quello ci vorrà l’integrazione del componente nepomuk-kde, ancora in playground (e non riesco nemmeno a compilarlo)
@Pedro:
Grazie a te per aver apprezzato, Drinho ;)
@lolloso:
Adesso sono 75MB per 2.700 file, ma c’è da dire che uso il backend redland, più avido di risorse rispetto a sesame2, che permette indicizzaione più veloce e meno uso di spazio su disco. Detto questo, non mi sembra così male.
@Flavio Castelli:
Concordo con te e con l’approccio realistico: da parte di GNOME non si accetterà mai di utilizzare Strigi… quindi tanto vale promuoverlo a pieni voti come servizio di KDE.
Grazie mille per la preziosa e puntuale analisi! :)
@Henryx:
Di paragoni tra Tracker, Beagle e Strigi abbonda la rete. Credo che uno dei più affidabili e rigorosi sia quello condotto da Sun Microsystems[1], che riconosce appunto Strigi la velocità e il basso consumo di risorse.
[1] https://pollycoke.net/2007/01/17/ricerca-desktop-beagle-tracker-e-strigi-a-confronto/
Sei vantaggi reali saranno quelli prospettati da Flavio ben venga questa integrazione, nonostante creda di capire in parte l’arrabbiatura di Jos.
Comunque, allo stato attuale, come si usa nepomuk/strigi con kde?
E poi chiedo: è comune che i servizi di nepomuk mi ‘ciuccino’ >400 MB di ram ?! A me capita spesso.
Ciao a tutti
@felipe: ah ecco, cribbio mi stavi a far pigliare un coccolone :))))
[...] strettamente parte di KDE), il famoso desktop semantico Nepomuk (ma ci stiamo arrivando, cfr “Strigi diventa un servizio di KDE: polemica, vantaggi“), il famoso e in teoria innovativo menu Raptor, la completa adozione di WebKit, la completa [...]
Forse parlo a sproposito, ma rendere Strigi con server, no? Poi ogni DE che desidera usarlo nel proprio sistema scriverà opportuni client o API per interfacciarsi ad esso. Così avremo GUI GTK+ e QT…
@DnaX: è l’approccio che è stato sempre seguito
@15:
Quell’approccio è deskzop-agnostico, fattibile e sempre da molti progetti (e.g. NetworkManager).
Ma integrarsi in KDE consente di usare librerie e servizi specifici, senza reinventare la ruota (vedi post post #9).
Ok, ma non è possibile che il servizio sia proprio il client che comunica col demone? Ad esempio Solid informa il client dello spegnimento, quindi il quest’ultimo dice al server di interrompere l’indicizzazione. E’ troppo macchinoso?
@18
Sarebe una soluzione, anche se inusuale e porterebbe delle complicazioni del tipo
- Server che chiede al client di fare qualcosa per lui (!!)
- Che succede se hai più client? ne prendi uno a caso?
- potrei continuare
Beh, il server sta in attesa di comandi dal client (ovviamente). Il client comanda al server di iniziare l’indicizzazione, il sistema sta per spegnersi, Solid informa del fatto al client che a sua volta informa il server di strigi di terminare l’indicizzazione. Ci può essere solo un client a comunicare col server. Ovviamente chiunque può chiedere al client in uso di estrarre informazioni dal database o eseguire determinati comandi a seconda delle autorizzazioni del richiedente.
Questa sarebbe la mia malsana idea…
immagina il seguente scenario
- Io mi loggo e il cient dice al server di iniziare ad indicizzare.
- Crasha X, rimango col terminale (od alternativamente crasha il client)
- Il server continua ad indicizzare
- Stacco la corrente e continuo a batteria, tipicamente il server dovrebbe smettere di indicizzare a questo punto, ma dovrebbe informarlo un client che non c’è più …!
Insomma Solid è legato allo stato della macchina, il server è un singleton legato anch’esso alla macchina, ma poi ne facciamo dipendere le operazioni da un certo numero di client transient (vanno e vengono, crashano, si impallano, etc)
Ok, grazie, chiarissimo!