Hi there, This long E-mail is also a request for a review of the attached patch, Martyn. You can call me crazy for working on this until 24 'O clock, but I guess I wanted to have it done today. Because Ivan Frade told me he likes the concept of letting applications push in data into Tracker for many situations, we decided to refactor the basis of the Evolution support that I recently finished [1]. [1] http://live.gnome.org/Evolution/Metadata (note that this is now a desktop neutral standard) I made this part GModule based. Meaning that you can add more such "Evolution like" modules. That is also the plan. For example one module for KMail and very different one for an RSS web grabber will be made very soon. Perhaps we'll make other ones for other kinds of apps too. How it works is simple, but can get a little bit confusing to read in C. I recommend reading this Vala example, as it does the same thing [2]. [2] http://live.gnome.org/Vala/DBusClientSamples/Waiting In Tracker a few more things got added, like the GModule support. tracker-push.c in trackerd is more or less a GModule loader and at the same time what the Vala example does [2] (go read it, in code it's much more easy to grasp than reading this gibberish explanation!): -> Do a ListNames on DBus initially and if our service is among the ones we want to consume, we more or less launch the GModule's capabilities. -> Then we start listening for NameOwnerChanged to know when we either need to shutdown the GModule's capabilities, or when we need to launch it. Use-cases: o. Evolution is not running, trackerd starts. User now starts Evolution. The NameOwnerChanged will detect this event and will launch the GModule for Evolution. o. Evolution is running, trackerd starts. ListNames will find the service for us and our handler will therefore launch the GModule. o. We were once registered with Evolution, we're still running. But now Evolution shuts down. The NameOwnerChanged will detect this event and will disable the capabilities of the GModule for Evolution. Now replace Evolution with KMail if you prefer the KDE desktop. Same story. We decided to refactor this because we want to enable Vala, Python, C#, Perl, D, C++, YodaYodi++#1^^ developers to develop modules. This means that it's all GObject & GModule based now. You install a GModule that has a function that returns a GObject that implements some methods in a directory A, and one in a directory B. Why two? Well one for the indexer and one for the daemon. The deamon is for your 'things' that need to be kept alive for a long time. The indexer is for your 'things' that will do a lot of DB transactions and insertions. For for example the Evolution one the deamon one proxies RDF triples to the indexer one for this reason. You can take a look at the existing Evolution one's Makefile.am to see how to deal with that, where to install it, etc. Anyway, here's the patch. Please review asap as we'll need this for followup tasks soon (like the RSS and the KMail support). Thanks! -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be
Attachment:
refactor-evo-support.diff
Description: Text Data