Cosa è stato completato?
- Tutto il codice del database è ora fuori dell'indexer. Ora l'indexer utilizza il tracker-store. Ordina al tracker-store di immagazzinare medatadi. L'indexer ora interroga il tracker-store per cose come la data di modifica. Al momento non ha accesso al database direttamente. Questo potrebbe cambiare per ragioni di performance, ma non siamo ancora sicuri.
- Il processo trackerd è stato rinominato tracker-store
- L'oggetto DBus nel tracker-store adesso esegue da solo le richieste di SPARQL Update. È utilizzato per mandare questa richiesta al tracker-indexer.
- E' stato spostato il codice per il watching e crawling che era nel demone all'indexer. Questo significa che il tracker-store non dipende più da inotify. Questo lavoro ha reso possibile creare il proprio indexer o non avere un indexer del tutto. Questo è stato un grosso compito ed è stato realizzato oggi. Questo naturalmente lo stiamo testando al momento.
- Philip Van Hoof ha scritto una API interna per mettere in coda le store requests al database, rendendo possibile in modo asincrono il trattamento di grandi quantità di dati quando consegne multiple di metadati dratanno al tracker-store ordini per immagazzinare i loro metadati.
- Ho anche realizzato il porting del codice esistente per utilizzare questa API interna. Questo task sta procedento e lo stiamo testando. Per esempio il Turtle Import, il supporto per la cache di dispositivi rimovibili in Turtle, i moduli Push (il supporto per i client di posta) e il DBus SPARQUL Update API sono influenzati da questo.
- La classe signals, la quale adesso non richiede il coinvolgimento dell'indexer, è stata sistemata.
Al momento l'indexer istruirà un processo di estrazione per estrarre i metadati da un file. Questo processo comunica i metadati prima all'indexer, il quale rigira gli stessi al tracker-store. Questo può essere fatto in modo più efficiente lasciando l'estrattore comunicare i metadati direttamente al tracker-store.
0 commenti:
Posta un commento