2007/3/4, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mikkel.kamstrup@gmail.com</a>>:<div><span class="gmail_quote"></span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2007/3/2, Jos van den Oever <<a href="mailto:jvdoever@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jvdoever@gmail.com</a>>:<div><div><span><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2007/2/28, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mikkel.kamstrup@gmail.com</a>>:<br>> Calling all desktop search gurus of the known web,
<br>><br>><br>> We are nearing deadline for the search spec (see
<br>> <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>),<br>> and I have collected a few highlights of my discussions at FOSDEM.
<br>><br>> - Generally there where interest in better introspection capabilities to
<br>> have dynamic UIs that adapt to the features of the search engine.<br>><br>> - The ShowSearchTool method in the UI interface was greatly criticized.<br>> Should we - or should we not, have it? As a deskbar dev I would like it,
<br>> since not everybody likes live results, but if deskbar would be the only<br>> consumer then I think I could accept life without it :-)<br>><br>> - We need some command line tools to test and help developing the backends.
<br>> I (Mikkel Kamstrup) volunteered to do some in python/glib.<br>><br>> - There was desire to add a way to introspect all indexed field names (not<br>> all indexers might support the entire metadata spec when it is ready)
<br>><br>> - In the end user search spec<br>> (<a href="http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage
</a>)<br>> it should be clarified that you can use words or phrases (with modifiers) as
<br>> values in Selectors. As the spec stands now it is actually there if you read<br>> carefully, but it can be visualized via the structure drawing as well (see<br>> the wiki page for new+old version).<br>>
<br>
> - How should we cater for remote search services or searches on remote<br>> machines (it is not necessarily the same)?<br>><br>><br>> Proposed "diff" to the current API:<br>> ----------------------------------------------
<br>><br>> - Add a session parameter to the GetQueryExtensions method, so that the<br>> signature becomes GetQueryExtensions (in s session, out as extensions) since<br>> there might be some future query extensions where their availability
<br>> actually depends on the session state.<br>><br>> - Add a session property that holds the supported Wasabi spec version of<br>> the backend<br>><br>> - Rename the session properties sort.property.{primary
,secondary} to<br>> sort.{primary,secondary}.<br>><br>> - Method to inspect the state of the indexer, something like GetState(out<br>> as state_info), where state_info is an array of two strings - a key-value
<br>> pair. Keys could be IDLE, UPDATING, and FULL_INDEX. The IDLE value should be<br>> ignored. The value of UPDATING is either the empty string or a string<br>> formatted integer denoting how many % the update is done (at 100% you should
<br>> change state to IDLE). The value of FULL_INDEX is the same as UPDATING.<br>> IDLE, and UPDATING, should be self explanatory, FULL_INDEX is used when the<br>> indexer is generating a new index from scratch.
<br>
><br>> - Add a StateChanged signal with signature StateChanged (in as state_info)<br>> - see item just above for description of argument.<br>><br>> - Add a GetFieldNames(in s session, out as field_names) method to inspect
<br>> the names of all indexed fields. This is useful for runtime cluster<br>> extraction and advanced UIs.<br>><br>><br>> Undecided<br>> --------------<br>><br>> - Can we control remote searches and other search scoping entirely via
<br>> session properties? I think we can... I think the Beagle devs are the only<br>> ones with real experience here though. If we can we can delay the exact<br>> specification of those properties a bit.<br>>
<br>
> - Add a method to introspect all supported session properties? In the light<br>> of the item just above this might make sense.<br>><br>I was at the discussions and agree with the above.<br><br>Cheers,<br>Jos</blockquote>
</span></div><div><br><br>Unless, someone shouts out, I'll add the above mentioned changes to the spec tomorrow.<br><br>More proposed diffs<br>--------------------------------<br> - Rename the method "NewSession" to just "Session"
<br><br> - Define dbus app name, object name, and interface names to be<br> - app name: org.freedesktop.wasabi.searcher<br> - object name: /org/freedesktop/wasabi/searcher/main<br> - interface: org.freedesktop.wasabi.search
<br><br>Why those names then? I like to call the app/object "searcher", because it's kinda closer to the Lucene IndexSearcher object naming, and that it has more of an application feel to it (instead of just ".search").
<br><br>I add /main to the object path for future extensibility.<br><br>interface name - since the wasabi spec compliance level is stored in a session property we don't need version hinting in the interface name.<br>
<br>
Coding<br>-----------<br>I'm writing my python based tools (for searching + dummy server), and things are progressing nicely. My hopes is that they can be used as a toolkit binding proposal too (api wise).<br><br>Code will be up in this week.
<br><br>Cheers,<br>Mikkel</div></div></blockquote><div><br><br><br>Hi all,<br><br>I pushed all changes I had to the wiki and I would like to call this RC1 until we have settled on the metadata spec. Or should we just be confident and call it final?
<br><br>List of changes since last:<br>----------------------------------<br><br> * Add method GetState and signal StateChanged for introspecting the whereabouts of the daemon.<br><br> * Change the value of session properties to Variant. This allows us to have multivalued properties in a clean way. See the "Session Properties" section for further details.
<br><br> * Rename the Search method to NewSearch to go better with NewSession and the Close{Search,Session} methods.<br><br> * Add session property "vendor.compliance" representing the version number of the Wasabi spec supported
<br><br> * Add session property "vendor.extensions" representing the supported query extensions that are supported<br><br> * Add session property "vendor.fieldnames" representing the supported/indexed metadata fields of the search engine
<br><br> * Remove method GetQueryExtensions since there is now a session property for this<br><br><br>Please give <a href="http://freedesktop.org/wiki/WasabiSearchLive">http://freedesktop.org/wiki/WasabiSearchLive</a> a good look before we set this in stone. It is the last call if you have any objections - I really mean it this time. Anything from critisizing the fundamental structure down to nitpicking on the session property names is welcome.
<br><br><br>Coding<br>---------<br>Regarding my wasabi toolkit I'm really close to having something was sharing - until my recent spec updates atleast. With a little luck I should be able to show you something pretty soon.
<br><br><br>Cheers,<br>Mikkel<br></div><br></div>
<br>