Edward Duffy wrote: > On 12/7/06, Jamie McCracken <[EMAIL PROTECTED]> wrote: >> it would be best to discuss this first before doing the patch (unless >> you are content to modify it quite a bit - which is fine!) >> >> I like this in general but there are a few things: >> > thanks..just wanted to get something out there. > >> I want it to work with third party packages so it needs to have easy >> installation and deinstallation >> > I agree, that's why I made the directory names the same as the > tracker.cfg keys. But, there still needs to be a way to update the > database when a new metadata class is added.
yes trackerd can read the service type in the service file and create a new service if it needs to we need a way to create new metadata types for the service too - might be tricky trying to list them in an ini file as they need data types as well as names > >> >> I would prefer just "services" to "external-services" > Naming isn't my strong suit. > >> >> >> Im not sure this is needed but I suppose there's no harm in having it >> but it should be optional > currently that's how it works. If check-deps isn't there, the module > is still used. >> >> >> not needed - I prefer to have a service file (like the dbus service >> files or .Desktop files which specify the options needed here). > Ahh. Sounds cleaner! > Only problem I can see with this is the Man Page indexer. It gets its > list of directories from the output of `manpath`. automake can handle that > >> >> All we need is a directory like /usr/share/tracker/services to hold the >> service files. This makes it easy for seperate packages to install and >> de-install stuff without any hassle. >> >> At start up trackerd can simply read all these service files (+ also >> watch for new ones too!) >> > cool...much better than it currently is. > >> > >> > 3) service-type >> not needed - any file in the watch directory above would be passed to >> the spawned service-handler (we can include globs in the service file to >> filter certain files to pass) > wasn't sure. >> >> generally these watched folders will all be in hidden folders (usually) >> so they wont conflict with the file indexer. >> >> > >> > 4) filter-text >> > 5) extract-metadata >> >> I was planning on migrating the existing metadata extractors format to >> an xml format (our current one is quite hacky!). We also need to handle >> multiple values for the same metadata type. > For instance, the "To:" field in an email? yes although i would keep email indexing internal due to the potentially large number of emails in an mbox > >> >> something like: >> >> <extraction> >> <metadata name="Audio.Title">Moonlight Sonata</metadata> >> <metadata name="Audio.Artist">Beethoven</metadata> >> </extraction> >> >> Feel free to modify code to match above. >> >> the filter program and metadata extractor program should be specified in >> the service file so there's no need to worry about mimes. > Again, the man pages were the problem. Some are gzipped, some aren't. the extractor program can tell that from the file name, surely? > >> >> We need a function in tracker-utils that determines if a file is >> associated with a particular service by looking at its path and matching >> it against any path thats registered as a watch by a service. We need >> this for the emails so may as well reuse it for all services. (just >> needs to call g_str_has_prefix on it) > Yeah, I put that code in the process_files_thread. > >> >> > 1) IndexManPages >> ok great. Maybe we can use user's locale to work out which translations >> to index? > >> >> > >> > 2) IndexTomboy >> see Mikkel's tomboy indexer which he sent on this list last month - it >> does all the fields I believe. Perhaps you could use some of his code? > must have missed that. I just use xsltproc, so it's no effort to add > the other pieces. >> >> > >> > 3) IndexLiferea >> not sure - will have to think. The xml above for the extractor could be >> modified to support multiple sub-entities with their own uri in one go. >> >> <extraction> >> <Entity uri="/home/jamie/music/moonlight.ogg"> >> <metadata name="Audio.Title">Moonlight Sonata</metadata> >> <metadata name="Audio.Artist">Beethoven</metadata> >> </entity> >> >> <Entity uri="/home/jamie/music/moonlight.ogg"> >> <metadata name="Audio.Title">Moonlight Sonata</metadata> >> <metadata name="Audio.Artist">Beethoven</metadata> >> </entity> >> </extraction> >> >> >> so in the DB, they should be separate objects "RSS" feed and "RSS Item" >> >> You could also build the uri to include the rss file and an offset to >> the item that matches and the gui can then decode it and show a viewer >> for it > file:///path/to/file#3 ??? yeah or use what evo does for its uri and use a semicolon instead of # /path-to-mbox;uid=11 you could then write a viewer app (in any language) to show the correct chunk >> >> >> the service file can contain this - either an exec name or a dbus >> interface/object name >> > ahh..I was wondering how to distiguish one Tomboy specific Note to a > non-Tomboy Note. non-tomboy notes would be in different directories surely? -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
