Hi Jamie,
1) instead of tracker-index shared lib, only the parser would be shared (because trackerd would need to parse and stem search terms). the search api would not need to be shared nor would any other indexing stuff.
Do you mean to split the API in two components: search and index? I fixed it in the diagram. I think it is just a question of how to compile the files.
2) trackerd's access to db/index would primarily be read only with exception of ontology updates. for safe NFS use we must avoid separate processes writing to same db at same time. so for storing metadata we would need to pause (via dbus) tracker-file-indexer if its indexing and writing to metadata db (for performance reasons we could include option not to do this and rely on file locking)
I suppose that we update the ontology only when trackerd is started. After that, we can launch tracker-file-index and both processes never write simultaneously in OntologyDB.
3) A User DB which is used for storing user defined metadata + services (tags + any services stored directly in tracker as their primary store like bookmarks and other stuff which is not stored elsewhere on disk)
This database is written by trackerd (when a client program uses the dbus-interface) and by tracker-file-index (e.g. to index a bookmarks file). So we could have some problems in NFS. Here we can use your solution (stopping tracker-file-indexer) when a client program try to add contents in this database.
4) ontology would be part of the metadata store. Both processes would need access to this and virtually no metadata operation could be completed without onto so does not make sense to separate them. As in (3) above metadata store would encompass the user metadata db as well as the indexed metadata db
Ok, i added a "libtracker-metadata" to handle "virtual data" (bookmarks, user-defined services, ...), metadata and ontology.
5) Shared config libs - not just for tracker but for tracker-preferences/tracker-applet as well
to sum up on shared libs i think the following is needed: * libtracker-metadata (read/write/search metadata) * libtracker-parser * libtracker-config * libtracker-common (shared utility functions)
Yes, it matchs with my result after apply your suggestions. Find attached a new version of the diagram. Ivan
Attachment:
tracker-processes-arch-2.jpeg
Description: JPEG image
Attachment:
tracker-processes-arch-2.dia
Description: application/dia-diagram
