[Wasabi Proposal] Live search API
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Sun Feb 4 23:39:10 EET 2007
2007/1/25, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> I updated http://wiki.freedesktop.org/wiki/WasabiSearchLive with a new
> property hit.properties.extended. I also added a new method
> GetQueryExtensions for introspecting which Wasabi query language extensions
> are supported (as was more or less agreed upon a while back).
> I'm really glad that it seems that we are finally converging on something
> :-) Unless someone come screaming soonish this is probably close to what
> will be the first public proposal (completing Milestone 1 when we have a
> user-level search language agreed upon).
I have some thoughts that might warrant a last-minute change/addition just
before MS1 (this tuesday)...
The initial motivation for splitting in a Simple and a (complex) Live dbus
API was to allow search engines to only implement the Simple api. But the
current proposal merges the two apis...
I suggest we add some way to introspect whether the search engine supports
the "block" and "live" (and other) session properties. There are three
options as I see it:
1) Add a method GetSupportedSessionProperties which returns a full list of
all supported properties (this also allows search engines to not support
sorting by any given field), all other properties are considered
2) Add a return value to SetProperty() the return value could fx be the
actual value used in the property. Then apps wanting live search could
assert ("true" == SetProperty(session, "live", "true")). This would also
allow "read-only" properties.
3) Rename GetQueryExtensions to GetEngineFeatures() and include *also*
supported properties in the result list (this way we'll have a big mix of
allowed query extensions and session properties)
I'm in favor of 2). Any other suggestions, or comments?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg