simple search api (was Re: mimetype standardisation by testsets)
Jos van den Oever
jvdoever at gmail.com
Sun Nov 19 13:19:45 EET 2006
Yes, the common dbus api is still something we need. I wanted to start
on the metadata standarization first, but we can do the searching api
in parallel. You make a good start in listing the available engines.
There might even be more. To coordinate we need a process that lists
the available search engines over dbus. An application should be able
to say: I want to search using a particular interface with the
available search engines.
The attached archive contains an effort to do two things:
- propose a very simple, common api for search engines
- implement such a coordinating daemon
The code contains the daemon, a demo search application and a python
client to access it by finding the search engine over the
The proposal for the search api is _very_ simple and I call for
application developers to see if the function calls in there are
Here i paste them for convenience:
method startConfiguration ( )
Open a graphical interface for configuring of search tool.
method countHits ( in s query , out i count )
Count the number of instances of a file that match a particular query.
The query being performed.
The number of documents that match the query.
method query ( in s query, in i offset, in i limit , out as hits )
Perform a query and return a list of files that match the query.
The query being performed.
The offset in the result list for the first returned result.
The maximum number of results that should be returned.
A list if filenames that are the result of the query.
method getProperties ( in as files,in a(sa(sas)) properties )
Get properties for the given files.
A list of files for which properties should be returned.
The properties belonging to each file. Each property is a name
associated with a list of string values. The index of each property
map in the list corresponds to the index of the filename in the list
2006/11/3, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > 2006/10/30, Jos van den Oever <
> > jvdoever at gmail.com>:
> > > To make it a bit more concrete (yes, you're probably not running
> > > strigi svn) here's some code that generates the xml output using
> > > kde3's metadata framework. I'm sure doing the same for other programs
> > > is easy too. Then comes the hard task: making it all consistent.
> > Here's already a new version of the kde3 code. I forgot to escape the
> > special xml entities.
> > It's probably a good idea to open up a project in svn for this stuff.
> > If there's enough interest about it, that is. Can someone arrange
> > that? The testcases should also go in there.
> > Cheers,
> > Jos
> Picking up the track from Gnome d-d-l I am interested in hearing if your
> are also looking into a unifying dbus api for desktop indexers? Being a
> deskbar developer I am greatly interested in this part of a potential spec.
> If you are more on the metadata extraction part of it now (as it would seem)
> I can try and make an overview of the current available apis, and try to
> make some form of synthesis we can use as a base for further discussion...
> PS: What indexers are around (and actively developed/maintained, and
> actually has working code):
> - Tracker http://www.gnome.org/~jamiemcc/tracker/
> - Beagle http://beagle-project.org/
> - Strigi
> - Pinot http://pinot.berlios.de/
> - GLSCube http://www.glscube.org/
> - Nepomuk
> http://nepomuk-kde.semanticdesktop.org (do
> they have any code?)
> xdg mailing list
> xdg at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8044 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061119/d2f1cfef/attachment.bin
More information about the xdg