Calling all desktop search gurus of the known web,<br><br><br>We are nearing deadline for the search spec (see <a href="http://wiki.freedesktop.org/wiki/WasabiRoadMap" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://wiki.freedesktop.org/wiki/WasabiRoadMap</a>), and I have collected a few highlights of my discussions at FOSDEM.
<br><br>&nbsp;- Generally there where interest in better introspection capabilities to have dynamic UIs that adapt to the features of the search engine.<br><br>&nbsp;- The ShowSearchTool method in the UI interface was greatly criticized. Should we - or should we not, have it? As a deskbar dev I would like it, since not everybody likes live results, but if deskbar would be the only consumer then I think I could accept life without it :-)
<br><br>&nbsp;- We need some command line tools to test and help developing the backends. I (Mikkel Kamstrup) volunteered to do some in python/glib.<br><br>&nbsp;- There was desire to add a way to introspect all indexed field names (not all indexers might support the entire metadata spec when it is ready)
<br><br>&nbsp;- In the end user search spec (<a href="http://wiki.freedesktop.org/wiki/WasabiRoadMap" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.freedesktop.org/wiki/Wasabi</a>UserSearchLanguage) it should be clarified that you can use words or phrases (with modifiers) as values in Selectors. As the spec stands now it is actually there if you read carefully, but it can be visualized via the structure drawing as well (see the wiki page for new+old version).
<br><br>&nbsp;- How should we cater for remote search services or searches on remote machines (it is not necessarily the same)?<br><br><br>Proposed &quot;diff&quot; to the current API:
<br>----------------------------------------------<br><br>&nbsp;- Add a session parameter to the GetQueryExtensions method, so that the signature becomes GetQueryExtensions (in s session, out as extensions) since there might be some future query extensions where their availability actually depends on the session state.
<br><br>&nbsp;- Add a session property that holds the supported Wasabi spec version of the backend<br><br>&nbsp;- Rename the session properties sort.property.{primary,secondary} to sort.{primary,secondary}.
<br><br>&nbsp;- Method to inspect the state of the indexer, something like GetState(out as state_info), where state_info is an array of two strings - a key-value pair. Keys could be IDLE, UPDATING, and FULL_INDEX. The IDLE value should be ignored. The value of UPDATING is either the empty string or a string formatted integer denoting how many % the update is done (at 100% you should change state to IDLE). The value of FULL_INDEX is the same as UPDATING. IDLE, and UPDATING, should be self explanatory, FULL_INDEX is used when the indexer is generating a new index from scratch.
<br><br>&nbsp;- Add a StateChanged signal with signature StateChanged (in as state_info) - see item just above for description of argument.<br>
<br>&nbsp;- Add a GetFieldNames(in s session, out as field_names) method to inspect the names of all indexed fields. This is useful for runtime cluster extraction and advanced UIs.<br><br><br>Undecided<br>--------------<br><br>
&nbsp;- Can we control remote searches and other search scoping entirely via session properties? I think we can... I think the Beagle devs are the only ones with real experience here though. If we can we can delay the exact specification of those properties a bit.
<br><br>&nbsp;- Add a method to introspect all supported session properties? In the light of the item just above this might make sense.<br><br><br>Cheers,<br>Mikkel<br>