Re: [Tracker] [WIP] Application support: man pages, Tomboy, & Liferea

["Edward Duffy" <eduffy gmail com>]

On 12/7/06, Jamie McCracken <jamiemcc blueyonder co uk> 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.

> 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`.

> 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?

> 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.

> 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   ???
> 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.

> Any comments?
>
> --
> Mr Jamie McCracken
> http://jamiemcc.livejournal.com/