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

[Joe Shaw]

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?

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.

Joe