GNOME.org
 

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

Edward Duffy wrote:

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.
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/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]