2006/11/30, Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, On Thu, 2006-11-30 at 09:32 +0800, Fabrice Colin wrote: > On 11/30/06, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> 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?</blockquote><div> 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... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> That's why I propose 2 apis :-) <a href="http://wiki.freedesktop.org/wiki/WasabiSearchSimple">http://wiki.freedesktop.org/wiki/WasabiSearchSimple</a> <a href="http://wiki.freedesktop.org/wiki/WasabiSearchLive">http://wiki.freedesktop.org/wiki/WasabiSearchLive </a> 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. </div> 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 </div>