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

[Jean-Francois Dockes]

Mikkel Kamstrup Erlandsen writes:

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

What I meant was that Lucene defaults to OR, Beagle to AND and that the
latter seems more intuitive to me but I don't really care either way. This
is just for clarification. There are mentions of the Wasabi language being
a Lucene subset on the draft page, this is wrong. No big deal, just to
avoid inconsistencies.

 > >   [about switch requirement list]
 > 
 > 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.

I have no problem with the list, just with the "mandatory" mentions. I
think that a back-end engine may still be useful if it doesn't provide an
"author" field, it may have other qualities :) The "group" idea is a very
good one I think, but we can imagine a user with a preferred engine
specialized for office files, who always searches office files and couldn't
care less about "group". Should we forbid this back-end of claiming or
aiming for wasabi compatibility because it doesn't do groups ? Maybe there
should be a "recommended" mention between mandatory and optional.


 > > [sample parser]
 > 
 > 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.

I agree. I think we should also have a toy/"throw away" implementation
quite fast, this will help with detecting problems in practice.


 > > [Beagle use of xml as serialization format]
 > 
 > Cool. Good that you took the time to look at this. Now we can dismiss that
 > option with confidence. Thanks.

Also goes to prove that you can turn a Beagle query into XML and back if we
had a doubt :)

jf