simple search api (was Re: mimetype standardisation by testsets)

Sun Nov 19 17:53:28 EET 2006

2006/11/19, Jos van den Oever <jvdoever at gmail.com>:
>
> Hi Mikkel,
>
> 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.

Agreed, that we need a dead easy way to get a list of search providers.

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

 Great work. I like your dbus api docs!

I must admit that I'm very keen on getting a daemonless spec. There's
already atleast one daemon running for search purposes, and having another
on top of that seems overkill.

I'd rather create library for finding search engines. This will require some
runtime negotiation but I don't think it will be a significant impact. I
have some rough ideas about a dbus api for this, I'll try and put it
together...

Of course if there are good arguments for a daemon then I'm willing to
reconsider... :-)

About org.freedesktop.search.simple:

org.freedesktop.search.simple.startConfiguration ():
 I would rather name it showConfiguration, but that is in the nit-picking
end of the debate. for a simple search interface I guess it is ok to have
coarse controls like this. A mote advanced interface could provide means to
set and get specific parameters on the search engine.

org.freedesktop.search.simple.countHits ( in s query , out i count ):
 Why is this necesary. Is it to accomodate use cases such as suggestion
popups like below[1], and reduce the dbus wire traffic for multiple calls?

[1:]
Type text in entry: net
Get a popup with:
            net   (7801)
            network (6578)
            netto (17)

org.freedesktop.search.simple.query ( in s query, in i offset, in i limit ,
out as hits ):
 What is the general consumer of this method? I don't see many. Only stuff
like deskbar-applet or a general search tool would use it. Maybe adding a
parameter to specify a list of groups the hits should match (or maybe
specifying mimetypes). This argument could be "*" or something to get all
kinds of results. I suggest changing the signature to:
query ( in s query, in as groups, in i offset, in i limit , out as hits )

each string in the groups array should belong to fx:
        "Files"
        "Folders"
        "Documents"
        "Images"
        "Audio"
        "Videos"
        "Development Files"
        "Conversations"
        "Playlists"
        "Applications"
        "Contacts"
        "Emails"
        "EmailAttachments"
        "Notes"
        "Appointments"
        "Tasks"
        "Bookmarks"
        "History"
        "Projects"

How about live queries? Maybe that should be supported in another interface
than the simple one.

org.freedesktop.search.simple.getProperties ( in as files,in a(sa(sas))
properties ):
 This seems good. It is a bit toward a metadata interface, but I think it is
good here to so apps don't need tons interfaces to work with. At some point
it there should be a specification on how to name and format these
properties/metadata.

I'll have a closer look at your work and follow up tomorrow.

Cheers,
Mikkel

The proposal for the search api is _very_ simple and I call for
> application developers to see if the function calls in there are
> sufficient.
> Here i paste them for convenience:
>
>
> interface org.freedesktop.search.simple
>
> 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.
> Input:
> query
>     The query being performed.
> Output:
> count
>     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.
> Input:
> query
>     The query being performed.
> offset
>     The offset in the result list for the first returned result.
> limit
>     The maximum number of results that should be returned.
>
> Output:
> hits
>     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.
> Input:
> files
>     A list of files for which properties should be returned.
> properties
>     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
> of files.
>
> 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...
> >
> > Cheers,
> > Mikkel
> >
> >
> > 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
> > http://www.vandenoever.info/software/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
> > http://lists.freedesktop.org/mailman/listinfo/xdg
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061119/bb8e87c6/attachment.htm 