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

[Mikkel Kamstrup Erlandsen]

2006/11/28, Joe Shaw <joeshaw at novell.com>:
>
> 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 I see where the disagreement comes from. Currently the premise for
the simple search api has been that it didn't need any language bindings.
Applications would certainly wrap the interface in a native object allowing
for mainloop integration, but it didn't need any code from the Wasabi
project to work.



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



Again such an api needs bindings for the toolkit being used. I'm not against
this - actually on the contrary, I just think that we should also have an
api that is easy to use even though you don't use the bindings for your
platform.

I still think it is possible to write a responsive ui with with the paging
queries instead of the fully async ones. An application need not request
1000 hits at a time it could send 10 queries requesting the hit ranges n*100
to (n+1)*100 for n=0..9. An example of this is the Tracker search tool and
the Tracker deskbar plugin (actually they only perform one query, but
still).

Another concern I have (that might be based in ignorance) is that a dbus api
with lots of temporary objects (queries) might be a lot of work for search
engines not having something close to this already. Maybe it is not that
hard to keep track of the objects, I really don't have much experience
here...


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



Yeah, I think the libbeagle api is nice to work with I give you that.

The ideal situation for me would be a "lowlevel" dbus api that could be used
directly or through some bindings for your platform. My intuition however
tells me that it might be better with a simple API resembling the currrent
proposal and another api to implement platform specific objects on.


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061128/5e743dfb/attachment.htm