2007/1/25, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>:

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[1]...

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

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?

Cheers,
Mikkel

[1]: http://wiki.freedesktop.org/wiki/WasabiSearchLive
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to