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

[Mikkel Kamstrup Erlandsen]

2006/11/30, Joe Shaw <joeshaw at novell.com>:
>
> Hi,
>
> On Thu, 2006-11-30 at 09:32 +0800, Fabrice Colin wrote:
> > On 11/30/06, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>
> wrote:
> > > Ok. My opinion is this:
> > >
> > > Create a simple api for direct use. No live queries, just batch
> deliverance
> > > and support for paging (much like the current spec on
> WasabiSearchSimple).
> > > The question on whether to standardize on a simple query (non-xml,
> maybe
> > > beagle-like syntax) language as well remains open.
> > >
> > > When we have the simple interface in place, create a "live" (or
> "full")
> > > interface to support live queries and what not. This includes a XML
> query
> > > language. This interface is intended for toolkit bindings (think
> native
> > > Client objects in QT/Gobject), but should be usable without these.
> > >
> > Agreed. Let's get a simple search interface working first without
> > anything fancy.
>
> Do we know who the end user here is going to be?  Have we talked with
> application developers about what they want?


Not really. That's why we must pair close attention to what the current
consumers does. I would really love to go out and talk to each and every
Gnome and KDE application maintainer, but that would require more people (on
the Wasabi end) and a more clear goal.

Read on...


I've been involved in adding Beagle support to both Nautilus and Yelp,
> and the use cases for the two are pretty different.
>
> For Nautilus, you're querying only for files, you want a basic search
> entry, you also want some advanced querying features (like limiting by
> mime type, or by path), and you want live queries.
>
> For Yelp, the use case is much simpler and probably closer to what other
> people are thinking.  You want to search only documentation, and you
> want a search entry, and that's it.  You type something in, you get back
> a list of URIs, the title for the document, and a small snippet.
>
> I can imagine for an audio player like Banshee you'd want to limit to
> only audio files, maybe some advanced property or date-range queries
> (show me only "Rock", or show me only things I've added in the last
> month), and you definitely want live queries.
>
> My question is: what's the target goal here?  Of my three listed use
> cases, the proposed simple API only covers one of them.  If our goal is
> to have a comprehensive, backend-independent search API, we're falling
> short.  If we're targeting a limited number of applications here, it's
> probably fine.


That's why I propose 2 apis :-)

http://wiki.freedesktop.org/wiki/WasabiSearchSimple

http://wiki.freedesktop.org/wiki/WasabiSearchLive

The Simple for apps that need static data (fx Yelp), and the Live for full
blown search bonanza (or at least it should match your other requirements).

The Simple api needs a simple query language (meaning the one that the user
types in), and the Libe api needs a full xml based query language which
could allow embedding of the simple language as you described Beagle does.


I suggest we agree on a Simple api and a Live api. When we have that we call
it Draft 1. Then send it around to various would-be-consumers, and do n
iterations of that procedure until we feel good everybody... (or atleast the
vast majority)

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061130/25eb5d98/attachment.htm