2006/11/26, Jean-Francois Dockes <<a href="mailto:jean-francois.dockes@wanadoo.fr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jean-francois.dockes@wanadoo.fr</a>>:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It's quite amazing how parallel thinking can bring people to the same point over a few days. I am in quite complete agreement with Fabrice's message and most of Wasabi2 or the recent edits by Mikkel on Wasabi. The initial stated goal for Wasabi is/was quite broad, "Unified dbus api for desktop search" was the subject of the email I received. This is what made me react quite energically to the proposal for a query language. After a few days of thinking, I now think that there are 2 distincts needs: 1- A need for trivial enabling of text search in any (non-search)     application, with minimal fuss, (better described by Fabrice in the     quoted message). 2- A more hypothetical need for an interface that would allow     *search tool* front-end writers to make use of different search     back-ends. The need for (1) is immediate and obvious, and maybe it should be made clearer that this is the initial goal for the Wasabi project. This would remove any major objection on my part about the simple query language on the WasabiDraft page. In this perspective, I would even be in favor of removing the specification in Wasabi2 that the on-bus language is structured. Let us just prefix the interface as Simple or Trivial or whatever, and let the backend deal with query string interpretation. As to (2), maybe we can put this on the back-burner for the time being. This is a more difficult project, and, if needed, it will be easy enough to extend Wasabi with an alternative query interface, while keeping compatibility for the non-search apps using the trivial interface. (There probably should be some mention of it somewhere on the project page though, to make it clear that we differentiate the two perspectives). Under the assumption that we are more or less in agreement, I have a few more comments about the simple interface:</blockquote><div> You can count me in on that assumption :-)  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> - About the query language, and just for the record, the syntax described   on WasabiDraft is more the one from Beagle than the one from Lucene   (which defaults to ORing, not ANDing the terms I think). This is probably   and appropriately more intuitive for end-users.</blockquote><div> Which is? AND or OR? This is kind of a religious thing I guess. At wotk we had a huge flame fest about this :-) We ended up ANDing... This was the ruling from our usability consultants, I work at a library, and the same usability rules might not apply to desktop search...  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> - I think that there are too many mandatory things in the 'switch'   list. For example, the 'group' concept, while interesting, is not   necessarily common back-end functionality. The 'author' switch might not   be so commonly supported either. I think that we should, specify a set of   standard switches, specify also that back-ends should just ignore   switches they don't know or support, and let them do their best.</blockquote><div> Yeah, I admit that the current requirements was a bit arbitrary, I just needed to put something there... The idea with author and title and such was to take dublin core into consideration (which should probably not be mandatory for indexers). The group switch is another deal. As I've pointed out before I think this is a really really useful switch to application developers, and as it has been pointed out elsewhere in this thread it is not always and easy task to group files. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- Should we provide one/several sample parsers to turn the query string   into a simple data structure ? This might help back-end adapter writers,   and also help remove any possible ambiguity from the language definition.</blockquote><div> There are several ways to do this. One idea could be to provide stand alone libs for QT and GObject... Ie. no "bindings" just pure implementations. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> PS: about Beagle and XML. There was a question about this somewhere, so I had a look this morning. From what I could see, XML is used only implicitely in Beagle as the serialization form for communication between the front-end and the beagled daemon. As this kind of serialization is supported directly by the standard C# libraries, it's more or less transparent. The libbeagle C front-end library has to generate and parse the XML "by hand". I don't think that there is anything else than this ad-hoc use of XML, and I didn't see anything ressembling a document definition anywhere.</blockquote><div> Cool. Good that you took the time to look at this. Now we can dismiss that option with confidence. Thanks. Cheers, Mikkel  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Fabrice Colin writes: > On 11/24/06, Jean-Francois Dockes < <a href="mailto:jean-francois.dockes@wanadoo.fr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> jean-francois.dockes@wanadoo.fr</a>> wrote: > > Here follow my impressions after reading the Wasabi Draft document. > > ... > > Ok, enough for now, my only hope here is to restart thinking about the > > query language. > > > > I have given some thought to this over the weekend and here's what I reckon. > > We do need a simple text string-based query language.  The way I see it, > the main goal of Wasabi is to allow to plug any personal search system > into existing applications (file managers, toolkits' file chooser > dialogs, cataloguing software, etc...). These applications typically > only have a basic search user interface, i.e. a text field and maybe > some knobs that can be tweaked. > > Once we have sorted out the dbus interface, these apps will only have to > make a couple of method calls and pass the string entered by the > user. We should try to make it as easy as possible to run searches; any > parsing/formatting that's necessary on the part of these apps will add > complexity. The more complex it is, the less widely it will be adopted. > Since most end-users are familiar with the query format supported by > popular Web engines, we should go for something similar.  Leo mentioned > Lucene's query language. While I agree we should avoid tying anything to > a particular search toolkit, a subset of that query language might make > sense. If need be, an ABNF grammar would remove ambiguities. > > > On the other hand, I agree with Jean-Francois that a more powerful query > language is better in the medium to long term. I don't know which is the > most appropriate. > > I think a dual approach, as proposed on the second draft, makes sense. > > Fabrice > _______________________________________________ > xdg mailing list > <a href="mailto:xdg@lists.freedesktop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">xdg@lists.freedesktop.org </a> > <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.freedesktop.org/mailman/listinfo/xdg</a> _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>