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

[Joe Shaw]

On Tue, 2006-11-28 at 07:15 +0100, Mikkel Kamstrup Erlandsen wrote:
> I think everybody wants that (atleast I do). However the idea about
> org.freedesktop.search.simple was to have a *simple* interface. Here
> the simple only applies to the end user-app developers.

Yeah, I can certainly appreciate that.

>  1) Targetted at apps where searching is not the main functionality,
> fx. a music browser, or filemanager. 
>  2) There should be no query building on the application end. Just
> pass the string as entered by the user to quuery method.
>  3) Should be dead easy to drop in your app with only a few lines of
> code

I agree in principle, but I disagree with point number #2 here.  One
reason is that it's generally not a good idea to programmatically build
a string query.  They can be error prone but more importantly they're
just slow.

Take a look at the Beagle backend in Nautilus:

        http://cvs.gnome.org/viewcvs/nautilus/libnautilus-private/nautilus-search-engine-beagle.c?annotate=1.2.2.1
        
(roughly around line 180)

The API is still very simple, but we set some important details on the
query to limit its scope:

        * We only want files; no emails, IM logs, addressbook contacts,
        etc.
        
        * We want a maximum of 1000 hits.
        
        * Optionally, we may only want a set of certain MIME types.
        
And we also obviously set the string the user typed in, which is
actually a query language string, so they can add more advanced
properties, like 'author:"Charles Dickens"'.
        
I think it would be a much uglier and harder to parse API if we had to
use a GString and keep appending these values as strings.

> The problem is that 2) warrents a simple search language to be defined
> to make much sense... 3) is a bit against the nature of your
> suggestion.

I think the simplicity of the Beagle API belies your assertion on point
3.  Moreover, not making it asynchronous is going to drastically reduce
the usefulness in GUI apps.  There are dozens of examples in GNOME alone
that show this.

Writing responsive GUI apps is Just Hard.  The Beagle API has tried to
make this as simple as possible.  You can implement a fully working
asynchronous Beagle client that fits in with the GLib main loop in about
100 lines:

        http://cvs.gnome.org/viewcvs/beagle/libbeagle/examples/beagle-search.c?annotate=1.4

We could add a synchronous API to this -- which wouldn't have the
benefits of Live Queries -- but to still have it work correctly in a GUI
app you would have to do all of your searches in a thread.  At least in
C, that's definitely harder to do than integrating with the main loop.

> A signal driven query response is dead easy to work with when you
> Query object is a gobject, but when it is a dbus object matters get (a
> little) more tricky. I'm not totally against this idea (signal driven
> query response), but I can't see how we could KIS. 

Recall that the low-level D-Bus APIs are not for application authors,
though.  Although most of the bindings aren't quite there yet, app
authors should be targetting GLib, QT, Python, Mono, etc. bindings.  And
that would map D-Bus signals onto callbacks in the native platform.  I
don't think it's a good idea to intentionally cripple an API to work
around a (temporary) deficiency in the platform.

> Do you have any specific idea for a dbus interface?

I don't have anything concrete in mind, but mapping something like the
Beagle query APIs onto a D-Bus interface seems like a decent first step.

Joe