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

[Jean-Francois Dockes]

By the way, I had a go at implementing the simple api, just to get myself
better acquainted with dbus.

I still think that a trivial interface may be useful. The current one makes
things unnecessarily complicated in my opinion.

Especially, returning the initial result as a sequence of uris (presumably
ordered by relevance), and then using them as keys to retrieve properties
is very awkward on the server side (forces maintaining a map from uris to
result entries).

I think it would be much simpler to have a single call like:

Query (in s query, in i offset, in i limit, in as properties, out aa{ss} hits)

where 'properties' is the list of requested properties, and 'hits' is an
array of property (name,value) maps, one for each result entry.

Uri and snippet are just two properties among others. I can't see any point
in having separate GetProperties() and GetSnippets(), and the list of uris
that the current Query() currently returns is mostly useless. The current
GetProperties() and GetSnippets() calls can be emulated by separate Query()
calls requesting adequate property lists if someone really likes them.

I think that this approach is simpler both on the server and application
sides.

Regards,

J.F. Dockes




Mikkel Kamstrup Erlandsen writes:
 > I just updated the Live api draft at
 > http://wiki.freedesktop.org/wiki/WasabiSearchLive. Please have a look and
 > comment here or on the wiki.
 > 
 > About libbeagle "compatibility":
 > I think that the suggested api is equivalent with libbeagle (in the sense
 > that they can implement each other). Atleast regarding the searching aspects
 > of the operations - the libbeagle api seems tailored towards communicating
 > with the beagle daemon (which makes perfect sense), but many of the
 > abstractions does not make sense as such in dbus centered search api...
 > 
 > Cheers,
 > Mikkel